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This  dissertation  discusses  the  integration  of  structural, 
functional  and  control  knowledge  in  manufacturing  workcell 
modeling,  simulation  and  design.  After  an  overview  of  applications 
of  semantic  and  object-oriented  data  models  in  the  manufacturing 
domain,  issues  relating  to  the  control  synthesis  for  manufacturing 
workcells  are  presented.  In  particular,  a  data  model  encompassing 
functional  and  control  features,  along  with  application  domain 
structural  knowledge,  is  developed.  This  model  assists  in  explicitly 
representing  the  control  aspects  of  engineering  design  within  an 
object-oriented  data  base  and  supports  a  task  level,  functionality 
driven,   manufacturing   workcell  design. 
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Since  manufacturing  workcells  consist  of  a  number  of 
elements  interacting  in  a  complex  manner,  workcell  control  design 
is  one  of  the  most  difficult  steps  in  the  workcell  design  procedure. 
Message  passing,  commonly  used  in  object-oriented  databases, 
provides  no  explicit  modeling  of  the  database  behavior.  Hence,  it 
cannot  serve  as  a  tool  for  the  design  of  system  control.  On  the  other 
hand,  Petri  nets  have  proven  successful  in  describing  complex 
interaction  among  active  agents.  This  work  explores  the 
incorporation  of  Petri  nets  as  a  basis  for  describing  application 
control   knowledge  within    a   structure-function-control   data    model. 

A  manufacturing  workcell  design  methodology  is  outlined, 
which  makes  use  of  the  proposed  tools  and  ideas.  This  methodology 
is  intended  to  be  used  as  the  skeleton  of  a  software  tool  that 
assists  in  the  manufacturing  workcell  design  process. 
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CHAPTER  1 
INTRODUCTION 


During  the  last  few  years  we  have  been  witnessing  a  dramatic 
change  taking  place  in  the  field  of  manufacturing.  Due  to  intensified 
foreign  competition  and  the  increase  in  cost  of  labor  and  materials, 
we  see  a  widespread  introduction  of  programmable  automation  in 
manufacturing.  Programmable  equipment  such  as  robots, 
numerically  controlled  machines,  and  sensors  provide  increased 
flexibility  with  the  trade-off  of  increased  complexity.  The  basic 
unit  of  a  manufacturing  facility,  the  manufacturing  workcell 
consists  of  an  integrated  set  of  programmable  devices  capable  of 
performing  certain  manufacturing  functions.  Flexibility  at  the 
shop-floor  level  and  factory-wide  Computer  Integrated 
Manufacturing  (CIM)  are  the  fundamental  paradigms  that  have  been 
proposed  in  order  to  achieve  manufacturing  goals  such  as  low 
production  cost  and  reduced  time-to-market  for  new  products. 
Whatever  the  manufacturing  strategy  being  pursued,  its  performance 
and  success  are  largely  dependent  on  the  use  of  state-of-the-art, 
cost-effective  manufacturing  workcells,  optimized  for  the  required 
application   domain. 

In  current  practice,  manufacturing  workcell  design  requires 
extensive  human  effort  in  terms  of  time,  cost  and  expertise,  thus 
preventing   full   achievement  of  the   potential   benefits  of  automation. 
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A  diverse  team  consisting  of  individuals  from  different  engineering 
areas  starts  by  generating  an  initial  design  that  satisfies  the 
manufacturing  requirements.  Very  frequently  the  workcell  has  to  be 
physically  built,  tested,  and  further  modified  if  necessary.  The  team 
may  need  to  iterate  through  this  process  several  times  until  the 
implementation  meets  the  specified  requirements.  The  overall 
process  is  very  difficult  and  time-consuming  [Levas  and  Jayaraman, 
1989;  Papaconstantinou  et  al.,  1989b].  A  1986  study  comparing 
Flexible  Manufacturing  Workcell  development  times  in  the  U.S.  and  in 
Japan  showed  figures  of  2.5  to  3  years  and  1.25  to  1.75  years, 
respectively  [Jaikumar,  1986].  Similar  figures  were  obtained  in 
1989  through  informal  interviews  of  electronic  and  mechanical 
assembly  workcell  manufacturers  [Fernicola,  1990].  Such  a  long 
development  time  is  convincing  proof  of  the  technical  difficulties 
inherent  in  manufacturing  workcell  design.  This  fact  often  promotes 
a  conservative  approach  to  workcell  design  that  largely  relies  on 
minor  variations  of  an  established  solution  and  its  adaptation  to  as 
many  applications  as  feasible.  This  results  in  deterring  many 
significant  design  improvements  and  the  timely  incorporation  of 
technological  advances  as  they  become  available  [Caselli  et  al., 
1990]. 

Even  though  computer  tools  have  been  used  for  a  long  time  in 
specific  areas  such  as  Computer-Aided  Design  (CAD),  Numerically 
Controlled  (NC)  machine  programming  and  individual  equipment 
programming,  limited  support  exists  for  overall  manufacturing 
workcell  design,  especially  when  compared  with  highly  automated 
areas  like  electronic  design. 
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In  recent  years,  advances  m  several  computer-related 
technologies  such  as  speed  of  computation,  graphics  interface 
capabilities,  software  engineering,  data  base  systems,  artificial 
intelligence,  as  well  as  the  increased  worldwide  economic 
competition,  have  stimulated  efforts  towards  the  development  of 
new  tools  for  manufacturing  workcell  design.  These  new  efforts 
could  be  observed  in  both  research  laboratories  [Levas  and 
Jayaraman,  1989;  Papaconstantinou  et  al.,  1989b]  and  industry 
[Silma,  1989;  Tecnomatix,  1989;  Deneb,  1990].  Such  tools  can  offer 
a  very  significant  payoff,  since  there  is  a  great  potential  for 
improvement  in  the  workcell  design  domain.  However,  the  lower 
degree  of  standardization  existing  in  workcell  equipment  with 
respect  to  other  domains  (i.e.,  electronic  devices)  is  an  inherent 
difficulty.  Furthermore,  even  though  the  number  of  devices  within 
the  workcell  may  be  small  (i.e.,  in  the  10-20  range),  each  workcell 
component  can  be  very  complex  (i.e.,  a  robot,  or  a  5-axes  machining 
center).  Thus,  the  development  of  a  CAD  tool  for  workcell  design 
calls  for  hierarchical  modeling  and  design  techniques.  As  part  of  the 
continuous  research  effort  on  this  subject  at  the  Machine 
Intelligence  Laboratory  of  the  University  of  Florida  since  1985. 
work  has  been  devoted  to  the  application  of  advanced  data  modeling 
techniques  in  the  development  of  support  tools  for  manufacturing 
workcell  operation,  modeling  and  design  [Govindaraj  and  Doty,  1986; 
Desai  et  al.,  1988;  Pal,  1988;  Papaconstantinou  et  al.,  1989a; 
Fernicola,    1990]. 

Currently,    the    expertise    required   for   manufacturing    workcell 
design  is  large  and  scattered  among  many  different  sources,  such  as 
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parts  catalogs,  human  experts  and  templates  from  previous  designs. 
Design  productivity  can  be  greatly  improved  by  the  integration  of 
this  body  of  knowledge  by  means  of  proper  database  management 
techniques.  However,  the  inadequacy  of  traditional  data  models 
(relational,  network,  hierarchical)  in  the  engineering  context  has 
been  amply  demonstrated  [Eastman,  1981]. 

Recently,  advanced  data  modeling  paradigms  such  as 
object-oriented  and  semantic  data  models  have  been  proposed  as 
viable  tools  for  conceptual  modeling  in  the  manufacturing  domain 
[Hull  and  King,  1987;  Spooner  et  al.,  1988;  Su,  et  al.,  1989].  These 
paradigms  can  cope  with  hierarchical  and  heterogeneous  knowledge 
as  well  as  support  complex  data  types.  These  models  provide  the 
following: 

Abstraction;  Designs  can  be  represented  at  various  levels  using 
the  same  model  by  suppressing  unnecessary  details. 

Semantic  Descriptive  Mechanisms:  The  models  allow  a  variety 
of  building  blocks  to  describe  designs  or  design  activities  with  a 
rich,   yet   machine-processable   description. 

Integritv  Constraints:  It  is  possible  to  state  relationships  and 
constraints   that   restrict   allowable   designs. 

Existing  object-oriented  and  semantic  data  models,  although 
providing  us  with  useful  tools  and  facilities  such  as  the  ones  just 
mentioned,  are  designed  for  general  use.  This  generality  in  these 
data  models  introduces  a  problematic  concept  called  semantic 
overloading  [Hull  and  King,  1987;  Atwood,  1991].  Semantic 
overloading  in  data  models  refers  to  the  use  of  a  few  basic 
constructs   to   convey   a   wide    array   of   meanings   and    relationships. 
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This  lack  of  expressive  power  prevents  full  use  of  semantic 
information  for  more  effective  data  management  policies  and 
integrity  enforcement.  In  order  to  alleviate  this  problem,  special 
semantic  associations  which  are  tailored  to  the  manufacturing 
domain  can  be  introduced.  These  additional  semantic  associations 
are  fine  tuned  to  the  application  domain  in  order  to  enhance 
modeling  power.  We  believe  that  the  trade-off  of  generality  for 
modeling  power  is  justifiable  in  a  very  specialized  domain  such  as 
manufacturing. 

Furthermore  we  see  a  need  for  an  additional  semantic  layer  to 
be  developed  on  top  of  these  general  purpose  data  modeling 
paradigms  in  order  to  support  a  dynamic  activity,  such  as 
manufacturing  workcell  design,  while  still  exploiting  all  the 
knowledge  embedded  in  the  available  design  specifications. 

In  particular,  it  has  been  pointed  out  in  the  literature  that  the 
engineering  domain  often  requires  integration  of  both  structural  and 
functional  knowledge  [Caselli  et  al.,  1990;  Cornelio  and  Navathe, 
1990;  Markowitz,  1990].  In  manufacturing  workcell  design,  control 
knowledge  also  plays  a  crucial  role.  Arguably,  since  manufacturing 
workcells  consist  of  a  number  of  agents  interacting  in  a  complex 
manner,  synthesis  of  the  control  logic  can  be  the  most  difficult  step 
of  the  overall  design  procedure.  However,  this  step  is  not 
adequately  supported  by  the  available  data  and  knowledge  modeling 
paradigms  and  is  typically  left  to  ad-hoc  or  brute-force  development 
techniques.  The  standard  object-oriented  data  base  technique  for 
object  interaction  modeling,  namely,  message  passing,  does  not 
provide     explicit    modeling    of    the     database    behavior    per    se. 
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Therefore,  message  passing  cannot  serve  either  as  a  system  control 
design  tool  or  as  a  document  of  system  behavior.  On  the  other  hand, 
Petri  nets  have  proven  to  be  successful  in  describing  complex 
interaction  among  active  agents  [Peterson,  1981;  Reisig,  1985; 
Murata,  1989;  Desrochers,  1990;  Teng  and  Black.  1990].  Chapter  7  of 
this  dissertation  explores  the  incorporation  of  Petri  nets  as  the 
basis  for  describing  application  control  knowledge  within  a 
structure-function-control    data    model. 

A  data  model  is  proposed  and  then  applied  to  the  workcell 
design  process  in  detail.  According  to  this  model,  functional 
knowledge  about  the  manufacturing  process  is  used  as  the  driving 
force     for     the     whole     design     activity.  Structural     objects 

corresponding  to  workcell  components  capture  the  structural 
knowledge.  Control  knowledge  is  expressed  in  the  form  of  Petri 
nets,  which  are  then  combined  with  constraints  derived  from  the 
functional  and  structural  objects.  The  goal  of  the  latter  activity  is 
to  synthesize  control  programs  for  the  agents  in  the  workcell. 

This  dissertation  specifically  investigates  the  use  of  object 
oriented  semantic  models  and  Petri  nets  as  the  basis  for  describing 
application  knowledge  within  a  Structure-Function-Control 
paradigm.  In  addition  it  attempts  to  show  their  usefulness  in  the 
workcell  design  process.  In  particular,  some  known  applications  of 
semantic  models  in  the  Computer  Integrated  Manufacturing  (CIM) 
area  are  reviewed  and  discussed.  These  applications  are  mainly 
related  to  the  modeling  of  existing  systems  and  scarcely  address  the 
support  of  workcell  design  activity.  A  simple  data  and  knowledge 
organization   for   manufacturing   workcell   design    is   introduced,   which 


is  expressed  by  means  of  semantic  associations  and  formulated 
using  a  subset  of  the  features  provided  by  complex,  state-of-the-ari 
semantic  data  models  [Su  et  al.,  1989;  Cornelio  and  Navathe,  19901. 
This  simple  model  is  then  enhanced  by  the  introduction  of  semantic 
associations  which  are  tailored  to  the  manufacturing  domain.  Nexi. 
the  role  of  the  functional  specification  of  the  manufacturing  process 
as  a  high-level  (task-level)  specification  driving  all  the  design 
activity  is  examined.  The  overall  design  process  is  illustrated, 
emphasizing  the  use  of  semantic  schemas  as  the  main  descriptive 
tools  capable  of  capturing  much  of  the  aesign  knowledge  requirea 
across  several  stages  of  the  design  procedure.  Furthermore,  the  use 
of  Petri  nets  as  the  basis  for  describing  the  application  control 
knowledge  is  explored.  The  Petri  net  representing  the  workcell 
control  can  be  used  in  order  to  verify  the  workcell  design,  through 
simulation.  In  addition,  after  verification  the  same  control 
structures  can  be  used  as  the  controlling  mechanism  of  the  physical 
workcell  at  run-time.  The  Petri  net  representation  has  been  proven 
to  be  an  intuitive  and  powerful  representation  in  describing 
interrelated,  complex  and  concurrent  activities  such  as  workcell 
controls. 

A  detailed  workcell  design  procedure  is  proposed.  According 
to  this  procedure  functional  knowledge  about  the  manufacturing 
process  is  used  in  the  early  stage  as  a  high-level  specification 
driving  all  the  design  activity.  This  functional  knowledge  is  then 
used  to  guide  and  constrain  the  workcell  equipment  selection 
(structural  components).  As  a  result,  of  this  activity  a  process  plan 
is     derived     within     the     functional     specification.         Finally,     a 
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methodology  is  provided  which  enables  the  transition  from  the 
functional  specification  domain  to  the  Petri  net  representation 
domain. 


CHAPTER  2 
DATA  MODELS 


The  traditional  database  models,  namely  relational, 
hierarchical  and  network,  were  the  dominant  data  modeling  tools  of 
the  1970s.  At  that  time,  computers  were  not  widely  available,  and 
their  use  was  mainly  restricted  to  large  corporations  such  as  banks 
and  government  agencies.  The  data  structures  used  by  these  models 
were  relatively  close  to  those  used  for  paper  and  pencil 
representation  of  the  data.  These  models  presented  the  data  as 
collections  of  records  with  printable  values.  These  models  are 
generally  referred  to  as  record-based  models  [Hull  and  King,  1987]. 
As  computer  technology  became  more  affordable,  these  traditional 
systems  started  appearing  in  engineering,  science,  statistical  and 
military  domain  applications.  Application  data  in  these  latter 
domains  are  more  complex  both  structurally  and  semantically.  The 
use  of  these  systems  in  increasingly  complex  domains  pointed  out 
their  deficiencies  and  limitations,  in  terms  of  both  functionality  and 
speed  [Su  et  al.,  1989]. 

By  the  time  the  engineering  domain  had  evolved  to  the  point 
where  data  management  became  a  real  issue,  the  relational  model 
had  supplanted  the  other  models  (i.e.,  hierarchical  and  network) 
[Atwood,    1991].   As  a  result  of  this  we   see  that,   of  the  traditional 
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models,  the  relational  model  [Codd.  1970]  and  its  extensions  came  to 
be  the  most  popular  ones  in  the  engineering  domain. 

A  brief  description  of  the  so  called  traditional  models  is  given 
below: 

Hierarchical  Model 
A  hierarchical  database  consists  of  an  ordered  set  of  tree 
types.  A  tree  type  consists  of  a  single  root  record  and  an  ordered 
set  of  zero  or  more  child  records.  A  child  record  can  itself  be  a  tree 
type.  In  effect  the  hierarchical  database  consists  of  a  forest  of 
trees.  A  restriction  imposed  on  this  structure  is  that,  with  the 
exception  of  the  root  nodes,  every  node  in  the  database  must  be  the 
child  of  a  single  parent  node.  Operations  for  data  manipulation  are 
at  the  record  level  (as  opposed  to  a  set  of  records).  Operators  are 
provided  for  locating  a  specific  subtree  in  the  database,  for  moving 
from  one  subtree  to  the  next,  for  moving  from  the  parent  to  the  child 
record  and  vice  versa,  and  finally  for  inserting  and  deleting  records 
[Date.   1986]. 

Network  Model 
The  network  model,  which  could  be  regarded  as  an  extension  of 
the  hierarchical,  allows  a  child  record  to  have  any  number  of  parent 
records.  Specifically,  a  network  database  consists  of  a  set  of 
multiple  occurrences  of  each  of  several  types  of  record  and  a  set  of 
multiple  occurrences  of  each  of  several  types  of  link.  Every 
occurrence  of  a  given  link  type  involves  a  single  occurrence  of  the 
parent  type,   together  with  a  set  of  occurrences  of  the  child  record 
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type.  Several  operations  are  provided  that  can  manipulate  this 
network  structure,  in  order  to  locate  and  retrieve,  delete  and  insert 
data  records.  As  in  the  hierarchical  model,  these  operators  are  at 
the  record  level  [Date,  1986]. 

Relational  Model 
The  relational  model  captures  data  in  a  set  of  relations 
(tables).  These  relations  consist  of  uniformly  formatted  records. 
Each  record  consists  of  an  ordered  set  of  attributes.  Attributes  are 
atomic  data  values  like  strings,  integers,  floating  point  numbers, 
dates,  etc.  Each  relation  has  an  attribute  (or  a  combination  of 
attributes)  that  uniquely  identifies  every  record  in  the  relation. 
This  attribute  (or  combination  of  attributes)  is  called  the  primary 
key  of  the  relation.  The  user  perceives  the  data  as  a  set  of  tables 
and  nothing  but  tables.  The  data  manipulation  operators  generate 
new  tables  from  old.  Therefore,  these  operators  are  producing  sets 
of  data,  not  record  instances  as  in  the  case  of  the  hierarchical  and 
network  models.  The  simplicity  inherent  in  the  relational  model 
made  it  very  popular  in  both  the  business  and  engineering  domains. 
When  used  to  model  complex  engineering  data  though,  the  relational 
model  exhibits  some  serious  problems.     Some  of  these  problems  are: 

1.  Only  a  single  primitive  (the  relation)  is  provided  for  handling 
both  real-world  objects  and  their  interrelations  [Atwood, 
1991].  This  phenomenon  is  commonly  known  as  semantic 
overloading  [Hull  and  King,  1987].  Whatever  semantics  are 
not    captured    by    the    model    need    to    be    represented    and 
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enforced    by   the    application    programmer   [Su    et    al.,    1989; 
Atwood,    1991]. 

2.  The  regular  record  structure  consisting  of  atomic  attribute 
values  is  incapable  of  explicitly  modeling  repeating  groups 
and  hierarchically  structured  information  [Haskin  and  Lorie, 
1982;  Lorie  and  Plouffe,   1983]. 

3.  The  disjoint  tabular  structure,  in  most  cases,  cannot  store 
close  together  all  data  belonging  to  a  single  object. 
Therefore  wnen  working  with  complex  objects,  performance 
is  poor  [Guttman  and  Stonebraker,  1982;  Vbase,  1988].  (A 
complex  object  is  a  collection  of  semantically  related  tuples 
from  different  relations  into  a  single  database  entity  [Haskin 
and  Lorie,  1982].) 

4.  Long,  variable  length  fields  are  not  fully  supported.  This 
generates  problems  when  the  application  calls  for  the 
storage  and  manipulation  of  data  objects  like  digital  images, 
Computer  Aided  Design  (CAD)  documents,  etc.,  data  types 
commonly  found  in  the  engineering  domain. 

5.  There  is  poor  separation  between  the  high-level  conceptual 
organization  of  the  database  and  its  physical  implementation. 

Realization    of    the    limitations    exhibited    by    the    relational 
model   generated   a   significant   amount   of   research    in    the    area   of 
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engineering  databases.  Improvements  and/or  extensions  of  the 
relational  model  have  been  reported  in  the  literature.  For  example, 
the  INGRES  relational  DBMS  (from  the  University  of  California, 
Berkeley)  and  the  System  R  relational  database  (from  IBM),  were 
extended  [Astrahan  et  al.,  1976;  Stonebraker  et  al.,  1984; 
Stonebraker  and  Rowe,  1986;  Row  and  Stonebraker,  1987; 
Stonebraker  et  a!.,  1987a;  Stonebraker  et  al.,  1987b].  Both  systems 
now  incorporate  complex  objects,  abstract  data  types,  procedures 
and  rules.  These  additions  were  attempts  to  enhance  the  relational 
model  in  such  a  way  as  to  make  it  a  sophisticated  database  tool  for 
the  engineering  domain. 

Semantic  and  Obiect-Oriented  (O-O)  Data  Mndel.s 
In  the  database  domain,  semantic  models  refer  to  data  models 
which  provide  a  set  of  modeling  constructs  capable  of  explicitly 
representing  the  semantics  of  the  application  domain.  These  models 
generally  provide  a  set  of  modeling  constructs  which  closely 
parallel  the  types  of  relationships  typically  arising  in  database 
application    areas. 

Historically,  semantic  database  models  were  developed  to 
support  the  conceptual  design  (early  stages  of  the  database  design) 
of  databases.  By  providing  higher  levels  of  abstraction,  these 
models  allow  the  designer  to  think  and  manipulate  data  in  ways  that 
correlate  more  directly  to  how  data  arise  in  the  real  world  [Hull  and 
King,  1987;  Gupta  et  a!.,  1989]. 

Some  of  the  best  facilities  provided  by  semantic  models  are 
the  following  [Hull  and  King,   1987]: 
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1.  Separation  of  the  conceptual  and  physical  components  of  data. 

2.  Decreased  semantic  overloading  of  relationship  types. 

3.  Availability   of   abstraction    mechanisms. 

4.  The  explicit  representation  of  objects  and  object  attributes. 

5.  The  explicit  representation   of  relationships  among   objects 

6.  Type  constructors  for  building  complex  objects. 

7.  Derived  schema  components. 

The  most  common  data  modeling  facilities  provided  by 
semantic  models  are  reviewed  next.  At  the  end  of  this  section, 
OSAM*,  a  powerful  object  oriented  semantic  association  model,  is 
reviewed.  This  model,  originally  proposed  in  Su's  work  [Su  et  a!., 
1989],  is  under  development  at  the  the  Database  Research  and 
Development  Center  of  the  University  of  Florida.  The  model  proposed 
in  this  dissertation  borrows  from  and  relies  heavily  on  the  OSAM* 
model. 

Most  semantic  models  distinguish  between  abstract  and 
printable  (or  representable)  data-types.  Abstract  types  are  usually 
used  for  modeling  physical  objects  such  as  robots  or  conceptual 
objects  such  as  manufacturing  plans.  These  abstract  types  are 
usually  assigned  a  unique  internal  object  identifier  (OID).  Printable 
data  types  are  typically  character  strings,  floating  point  numbers, 
integers,    etc. 

In  addition,  most  semantic  models  provide  mechanisms  to 
represent  atomic  and  constructed  data  types.  Atomic  types  are  non 
aggregate  objects  and  usually  draw  their  values  from  a  domain 
which   is   of  the   printable  type.      Constructed   data  types   are  types 
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which    result   from    an    association    (a    grouping)    of    either    atomic 
and/or  constructed  types  [Hull  and  King,  1987]. 

Semantic  models  provide  several  powerful  modeling  concepts. 
The  most  common  ones  are  reviewed  below  [Elmasri  and  Navathe, 
1989]. 

Classification  and  Instantiation:  These  two  operations  are  the 
inverse  of  each  other.  Classification  is  the  process  of  classifying 
similar  objects  into  object  classes.  In  effect,  it  defines  an 
abstraction  which  hides  the  individual  objects.  We  could,  therefore, 
manipulate  the  abstraction  instead  of  the  individual  objects 
themselves.  Instantiation  is  the  opposite  of  classification  in  that 
from  a  general  description  we  generate  a  particular  object  instance. 

Identification:  Identification  refers  to  the  concept  of  being 
distinguishable.  Unlike  the  relational  model  that  uses  an  attribute 
(or  set  of  attributes)  as  a  unique  identifier  (i.e.,  the  key),  most 
semantic  models  represent  objects  using  an  internal  identifier 
called  the  object  identifier  (OID). 

Generalization  and  Specialization:  Virtually  all  semantic 
models  provide  the  ability  to  represent  subclass/superclass  {ls_a) 
relationships.  Given  an  object  class,  sometimes  it  may  be  useful  to 
define  subgroupings  (subclasses)  of  this  class.  For  example,  the 
class     workcell      equipment    may     be    further     subdivided     into 
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Transportation 
equipment 


Workcell 
component 


Process 
equipment 


Auxiliary 
equipment 


Figure  1.     An  example  of  a  Generalization  (ls_a)  hierarchy. 


transportation,  process  and  auxiliary  equipment  (see  Figure  1).  The 
class  workcell  equipment  represents  more  general  properties  of 
objects  than  any  of  its  subclasses.  Every  object  that  belongs  to  any 
of  the  subclasses  has  to  belong  to  the  superclass  also,  therefore 
satisfying  the  ls_a  relationship.  This  relationship  can  be  viewed 
from  two  different  perspectives.  At  first,  consider  a  set  of  similar 
object  classes.  By  factoring  out  all  commonalities  from  these 
classes  and  placing  these  commonalities  in  a  different  class,  we  can 
generate  a  superclass.  This  newly  defined  superclass  could  be 
viewed  as  the  generalization  of  its  subclasses.  Another  way  of 
viewing  the  same  relationship  is  by  starting  at  a  class  and  forming  a 
set  of  subclasses  based  on  some  distinguishing  characteristics  of 
each  one  of  the  subclasses  (i.e.,  the  subclasses  are  more  specialized 
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than  the  superclass).     For  example,  the  workcell    equipment  class 
partitioned  into  three  subclasses  as  in  Figure  1. 


is 


Aaareaation  Association:  Aggregation  is  the  concept  of 
building  composite  (complex)  objects  by  combining  other  objects. 
This  association  captures  the  semantics  of  the  is  a  part  of 
relationship.  For  example  the  robot  class  in  Figure  2  is  defined  by 
combining  the  class  manipulator  and  the  class  controller.  Therefore 
every  instance  of  the  class  robot  is  made  up  of  a  manipulator  and  a 
controller. 


Robot 


Figure  2.    An  example  of  an  Aggregation  association. 


The  Object-Oriented  Semantic  Association  Model  (0SAM*1 
The   OSAM*   model   provides   a   conceptual   basis   for   uniformly 
capturing    the    semantics    and    interrelations    among    objects    in    an 
application.     It  possesses  most  of  the  concepts  and  features  of  the 
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object-oriented    paradigm    such   as   classification,    encapsulation   and 
multiple  inheritance.      In  addition  OSAM*   allows  for  the  definition  of 
rules  and  methods  as  a  part  of  an  object  class.     In  OSAM*  there  are 
two  types  of  object  classes: 

Entity  object  class  (E-class^:  This  class  models  objects  in  the 
application  that  are  accessed  independently.  It  is  represented  as  a 
rectangle  in  the  Semantic  diagrams  (See  Figure  1). 

Domain  obiect  class  (D-class^:  This  class  models  the  domain 
(e.g.,  the  type  of  data,  the  permissible  range  of  values,  etc.)  that  may 
be  used  by  some  other  class.  Therefore,  it  could  be  thought  as  an 
abstract  data  type.  A  D-class  is  represented  as  a  circle  in  the 
semantic  diagrams. 
An  object  class  may  contain: 

1.  A  set  of  associations:  An  association  defined  on  a  class 
captures  the  semantic  and  structural  relationship  between 
this  class  and  other  classes  (its  constituent  classes).  There 
are  five  semantic  associations  defined  in  OSAM*.  They  are: 
Aggregation  (A),  Interaction  (I),  Composition  (C),  Cross 
product  (X)  and  Generalization  (G). 

2.  A  set  of  methods:  These  operations  provide  high  level  access 
and  manipulation  of  the  class  and  its  objects. 

3.  Rules  and  constraints:  The  rules  are  used  to  derive  new 
information  and  the  constraints  are  used  to  maintain 
knowledge  base  consistency. 
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Of  the  above  semantic  associations,  the  ones  adopted  for  use 
in  this  dissertation   are  described  below. 

Aaareaation  Association  M):  An  E-class  can  have  an 
aggregation  association  with  other  classes.  This  association 
defines  a  set  of  attributes  for  the  defined  E-class.  The  constituent 
object  classes  serve  as  domains  for  these  attributes  and  can  be 
either  D  or  E  classes.  The  attributes  correspond  to  the  instance 
variables  of  object  oriented  languages. 

Generalization  Association  (G):  An  E-class  can  represent  more 
general  properties  of  objects  than  any  of  its  constituent  classes.  In 
this  case,  if  each  object  in  its  constituent  classes  is  also  an  object 
of  this  class,  then  this  E-class  is  called  the  superclass,  and  its 
constituent  classes  are  its  subclasses.  A  superclass  can  be  itself  a 
subclass  of  some  other  E-class.  The  OSAM*  model  supports  multiple 
inheritance,  therefore,  allowing  a  class  to  have  more  than  one 
superclass. 

Interaction  Association  (I):  An  E-class  can  be  used  to  model 
some  action  or  relationship  between  two  or  more  constituent 
E-classes  in  an  Interaction  association.  The  links  connecting  the 
E-class  with  its  constituent  E-classes  represent  attributes  of  the 
E-class.  The  cardinality  of  the  links  may  be  one-one,  one-many  or 
many-many. 

A  detailed  description  of  the  OSAM*  model  as  well  as  formal 
definitions  of  all  the  semantic  associations  are  given  in  the  paper  by 
Su  [Su  et  al.,  1989]. 
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CHAPTER  3 
MODELING  ISSUES  OF  THE  MANUFACTURING  DOMAIN 


Application  of  advanced  data  models  in  the  manufacturing 
domain  has  been  discussed  by  several  researchers  [Eastman,  1981; 
Nackman,  1985;  Spooner  et  al.,  1985;  Su,  1986;  Hull  and  King,  1987; 
Wedekind  and  Zoerntlein,  1987;  Jablonski  et  al.,  1988;  Ketcham  et 
al.,  1988;  Spooner  et  al.,  1988;  Staley  and  Boudreaux,  1988]. 
Actually,  the  manufacturing  domain  itself  has  motivated  much  of  the 
work  on  semantic  models,  stemming  from  the  perceived  inadequacy 
of  Data  Base  Management  Systems  (DBMS)  based  on  traditional, 
record-oriented  data  models  (relational,  network,  hierarchical)  in 
such  a  context. 

Peculiar  Features  of  the  Manufacturing  Domain 

The    manufacturing    domain    exhibits    peculiar    features,    when 

compared  to  other  classical  application  fields  of  DBMS  that  prevent 

a    profitable    use    of   the    more    traditional    data    models    [Su,    1986; 

Jablonski  et  al.,  1988].     Some  of  these  peculiarities  are  listed  below. 

1.  In  manufacturing  there  exists  an  explicit  hierarchical 
structure  of  the  application,  with  strong  data-locality 
properties.  This  structure  is  usually  known  in  advance 
[Jablonski  et  al.,  1988].     Often,  this  a  priori  knowledge  cannot 
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be   fully   exploited    In   the   relational    model.      The   "flat"   data 
surface  and  customized  user  access  policies  developed  by  a 
relational  DBMS  are  better  suited  to  the  business  domain. 

2.  The  computer  architectures  supporting  CIM  not  only  are 
distributed  and  hierarchical  by  nature,  but  are  also  invariably 
characterized  by  heterogeneity  in  the  processing  elements 
and  equipment  they  encompass.  The  latter  characteristic 
follows  from  the  fact  that  CIM  is  often  implemented  on  top 
of  existing  manufacturing  and  computing  facilities.  Even  for 
new  plants,  computer-controlled  manufacturing  requires 
specialized  equipment  typically  not  available  from  a  single 
supplier. 

3.  Manufacturing  workcell  devices  are  generally  viewed  by  the 
designer  as  entities  which  have  some  "state"  and  are  able  to 
exhibit  some  "behavior."  This  is  due  to  the  fact  that  these 
abstract  models  simplify  the  designer's  interaction  with  the 
device,  by  eliminating  unimportant  device  implementation 
details.  Object  oriented  techniques  could  be  used  to  build 
such  abstract  component  models  in  a  natural  way-natural  in 
the  sense  that  the  resulting  design  pieces  are  closely 
identified  with  the  real  world  objects  which  they  model 
[Korson  and  McGregor,  1990]. 

4.  The  manufacturing  domain  encompasses  many  different 
activities,     from     business-related     raw     parts     purchase, 
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product  sales  and  cost  accounting  to  highly  technical 
tool-wear  measurements  and  dynamic  production  scheduling. 
Support  for  complex  data  types,  such  as  engineering  drawings 
of  parts  or  Numerically  Controlled  (NC)  machine  programs,  iS 
also   required. 

Previous  Work 

This  section  reviews  some  of  the  previous  work  in  the  field 
and  highlights  those  issues  more  directly  relevant  to  manufacturing 
workcell   design. 

Advanced  data  modeling  techniques,  such  as  semantic  data 
models,  have  been  proposed  in  the  manufacturing  domain,  especially 
to  support  the  Computer  Integrated  Manufacturing  (CIM)  concept. 
Integration  of  the  many  diverse  factory  activities,  particularly 
data-driven  manufacturing,  requires  a  substantial  amount  of  data  to 
be  created,  manipulated  and  shared  or  exchanged  among  several 
decision  centers.  These  decision  centers  are  usually  located  on 
autonomous  processing  nodes  within  a  distributed  computing 
architecture.  Data-driven  manufacturing  refers  to  the  methodology 
within  CIM  for  automating  the  information  flow  between  product 
design  and  manufacturing  (CAD/CAM)  and  between  production 
planning  and  manufacturing  (CAPP/CAM).  Flexible  manufacturing 
further  increases  the  amount  of  data  to  be  processed  to  account  for 
on-line  production  switches,  tools  and  fixture  management  policies 
and  flexible  exception  handling.  Therefore,  innovative  automation 
paradigms,  especially  CIM,  require  support  of  a  full-fledged  DBMS 
[Jablonski  et  al.,   1988]. 
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Semantic  data  models  seem  to  offer  an  answer  to  at  least 
some  of  these  problems  (although  some  researchers  question  their 
capability  to  fully  address  the  issues  involved  in  the  manufacturing 
domain  [Papachristidis  and  Deen,  1988;  Spooner  at  al.,  1988].) 
Semantic  models  not  only  provide  a  common  reference  model  for 
data  sharing  across  heterogeneous  processing  elements,  but  also  can 
reflect  the  underlying  hierarchical  structure  of  the  application.  In 
addition,  by  providing  a  semantically  rich  model,  they  can  help  in  the 
integration  of  factory  activities.  A  recent  development  in  the 
advanced  database  field  is  that  of  object-oriented  (0-0)  semantic 
data  models  [Hull  and  King,  1987;  Spooner  et  al.,  1988;  Su  et  al., 
1989].  These  models,  while  sharing  with  the  semantic  models  the 
capability  to  express  complex  data  interrelationships,  also  provide 
mechanisms  for  encapsulation  of  complex  functions  within  the 
database  objects.  Thus,  object-oriented  models  are  capable  of 
specifying  local  behavior  as  well  as  allowing  access  to  dynamically 
created   and/or  derived    information. 

Semantic  models  have  been  mainly  applied  to  describe  the 
information  flows  and  local  data  at  different  machine  locations  so 
as  to  integrate  factory  activities  in  a  CIM  environment.  Less 
consideration  has  been  given  to  the  potential  application  of  these 
same  advanced  data  models  to  the  design  process  of  manufacturing 
workcells  and  equipment. 

Existing  work  on  procedural  guidelines  [Alami  and  Chochon, 
1985],  decision  support  systems  [Suri  and  Whitney,  1984],  expert 
systems  [Fisher,  1985]  and  graphical  modeling  and  animation  driven 
by  simulation  [Dombre  et  al.,   1986]  can  be  profitably  combined  with 
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advanced  data  modeling  and  a  corresponding  DBMS  for  the  design  of 
manufacturing    workceils. 

As  with  any  other  design  activity,  the  design  of  manufacturing 
workceils  consists  of  the  creation  and  manipulation  of  data  objects. 
This  exactly  matches  the  approach  of  the  object-oriented  paradigm, 
as  pointed  out  by  Spooner  [Spooner  et  al.,  1988].  Meanwhile,  the 
semantic  data  modeling  capabilities  provide  features  for  the 
construction  of  the  complex  objects  typical  of  this  domain,  by 
utilizing  the  relationships  between  objects  as  a  fundamental  part  of 
the  system  architecture  [Korson  and  McGregor,  1990].  Some  of  the 
issues  relevant  to  manufacturing  workcell  design  and  0-0  semantic 
models  are  the  following: 

1.  Currently,  the  expertise  required  for  manufacturing  workcell 
design  is  large  and  scattered  among  many  different  sources. 
These  sources  include  parts  catalogs,  human  experts  and 
templates  from  previous  designs.  Design  productivity  can  be 
greatly  improved  by  the  integration  of  this  Dody  of  knowledge 
using  proper  database  techniques. 

2.  The  hierarchical  and  heterogeneous  nature  of  such  knowledge, 
as  well  as  support  for  complex  data  types,  calls  for  an 
object-oriented    approach. 

3.  Object-oriented  semantic  models  provide  the  means  for 
integrity     enforcement,     richer     semantic     mechanisms     to 
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support   the   design    activity   and    a   wider   set  of   abstraction 
mechanisms. 

Achievement  of  the  potential  benefits  offered  by 
object-oriented  and  semantic  data  models  in  workcell  design 
requires  a  suitable  organization  of  the  domain-specific  knowledge 
according  to  the  selected  model. 
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CHAPTER  4 
THE  STRUCTURE-FUNCTION-CONTROL  PARADIGM 


In  any  application  domain,  knowledge  can  be  split  between 
structural  knowledge  (the  objects  and  physical  entities)  and 
functional  knowledge  (how  the  objects  behave  and  interact)  [Walker 
and  Thomas,  1985;  Caselli  et  al.,  1992].  This  separation  of  function 
and  structure  is  more  obvious  with  design  in  general  and 
particularly   engineering   design. 

In  most  object-oriented  data  models,  two  approaches  are 
typically  available  to  represent  the  functional  components  of  the 
domain.  One  approach  is  closer  to  the  original  object-oriented 
philosophy.  Functionalities  are  merely  owned  or  hidden  by  the 
structural  objects.  This  approach,  however,  while  providing  strong 
encapsulation  properties,  fails  to  capture,  in  a  satisfactory  way,  the 
functional  abstraction  hierarchy.  The  functional  hierarchy  is  usually 
not  isomorphic  with  the  hierarchy  defined  by  the  structural 
components  [Walker  and  Thomas,  1985;  Caselli  et  al.,  1992].  In  many 
engineering  contexts  the  functional  abstraction  is  often  as 
important  as  the  structural  one  [Blackburn  and  Thomas,  1985].  To 
fragment  and  hide  it  in  an  inconsistent  way  results  in  a  significant 
loss  of  application  domain  knowledge. 

An  alternate  approach  is  to  explicitly  model  both  structural 
and   functional   components   as    individual    objects,    using    the   same 
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object  syntax.  This  latter  approach,  however,  suffers  a  significant 
drawback  as  well.  Only  generic  associations,  characterized  by 
limited  semantic  expressiveness,  are  available  to  represent  a 
relationship  between  functional  and  structural  objects.  We  term 
these  associations  as  "semantically  weak"  [Caselli  et  al.,  1990].  For 
example,  in  the  object-oriented  data  model,  OSAM*  [Su  et  al.,  1989], 
a  single,  semantically  overloaded  association,  the  interaction 
association,  is  typically  used  to  relate  functional  and  structural 
objects.  Users  often  resort  to  "labeling"  this  association  in  order  to 
enhance  the  readability  of  the  resulting  schemas  with  descriptive 
names  or  additional  attributes.  However,  the  additional  semantics 
implicit  in  the  labeling  action  are  not  enforced  in  any  way  by  the 
model  itself.  As  a  result  the  burden  of  enforcing  these  semantics 
falls  on  the  applications  programmer.  This  problem  cannot  be  easily 
solved  in  models,  such  as  OSAM*,  that  are  designed  to  be  general 
purpose.  In  specific  domains  this  problem  can  be  relieved  by 
providing  a  richer  set  of  domain-dependent  primitives  in  addition  to 
the  single  interaction    association. 

Recognizing  the  modeling  problems  previously  discussed, 
recent  research  in  the  field  of  semantic  and  object-oriented  data 
models  applied  to  process  modeling  [Carswell  and  Navathe,  1986; 
Cornelio  et  al.,  1990a;  Markowitz,  1990;  Caselli  et  al.,  1992]  has  led 
to  modeling  paradigms  where  an  additional  semantic  layer  is  defined 
on  top  of  a  standard  object-oriented  model.  This  new  layer 
distinctly  represents  functional  and  structural  components  and  their 
relationships.      In   particular,   this   is   the   basic   rationale   underlying 
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the     Structure-Function     (S-F)     paradigm     proposed     by     Corneiio 
[Cornelio  et  al.,  1990;  Corneiio  and  Navatlie,  1990]. 

The  S-F  paraoigm  appears  to  successfully  represent  complex 
static  designs  in  the  manufacturing  domain  at  a  high  level  of 
abstraction  (e.g.,  for  CIM  databases).  However,  whenever  the 
knowledge  base  is  used  in  a  dynamic  way  for  design  purposes,  a 
large  gap,  both  practical  and  conceptual,  exists  between  the  S-F 
specification  and  an  implementation  satisfying  that  specification  as 
a  constraint.  Functionalities  represent  complex  behaviors  whose 
achievement  implies  the  realization  of  suitable  control  strategies. 
Many  different  control  implementations  can  be  developed  for  the 
same  high-level  specification.  Since  the  scope  of  the  S-F  paradigm 
is  restricted  to  high-level  modeling,  virtually  no  support  is  provided 
for  what  we  deem  a  fundamental  issue  in  manufacturing  workcell 
design,  namely,  the  development  of  an  implementation  whose 
correctness  and  compliance  with  the  specification  are  guaranteed  a 
priori  by  the  design  methodology  itself. 

These  are  the  basic  motivations  leading  to  the  proposal  of  a 
data  modeling  paradigm  oriented  to  the  manufacturing  domain  where 
proper  consideration  is  given  to  control  in  the  early  modeling  stages. 
To  express  the  semantics  of  control  we  use  Petri  nets.  They  have 
adequate  expressiveness  capabilities  and  represent  a  formal  model 
allowing  correctness  properties  to  be  demonstrated  [Peterson,  1981; 
Reisig,  1985].  Petn  nets  have  also  gained  wide  acceptance  as  a  tool 
for  modeling  and  control  in  the  area  of  manufacturing  [Kamath  and 
Viswanadham,1986],  and  have  already  been  shown  to  be  a  useful  tool 
for    automatically    synthesizing    and    programming    the    control    of 
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multi-agent  manufacturing  systems  [Crockett  et  al.,  1987;  Caselli 
and  Faldella,  1988;  Kasturia  et  al.,  1988;  Krogh  et  al.,  1988;  Thomas 
and  McLean,  1988].  An  extensive  list  of  papers  describing  Petri  net 
applications  in  manufacturing  can  be  found  in  a  paper  by  Desrochers 
[Desrochers,  1990].  In  addition,  Petri  nets  have  been  shown  to  be  a 
useful  tool  for  automatically  synthesizing  and  programming  the 
control  of  multi-agent  manufacturing  systems  [Courvoisier  et  al., 
1983;  Martinez  et  al.,  1986;  Murata  et  al.,  1986;  Crockett  et  al., 
1987;  Krogh  and  Sreenivas,  1987;  Caselli  and  Faldella,  1988; 
Kasturia  et  al.,  1988;  Thomas  and  McLean,  1988;  Willson  and  Krogh, 
1990].  As  will  be  exemplified  later,  we  extend  the  graphical 
formalism  of  semantic  schemas  to  represent  dynamic  behavior.  A 
relationship  can  then  be  established  between  the  schema 
representing  functional  knowledge  and  Petri  net  constructs  which 
will  enable  us  to  make  the  transition  from  one  representation  to  the 
other. 

The  Structure-Function-Control  (S-F-C)  paradigm,  an 
extension  of  the  S-F  paradigm,  states  that  to  represent  engineering 
knowledge  in  a  manner  conducive  to  complex  design  synthesis, 
physical,  functional  and  control  objects  are  modeled  individually. 
An  object-level,  many-to-many  (N:M)  mapping,  also  called 
provides/provided_by  link,  relates  the  structural  and  functional 
abstraction  hierarchies.  This  mapping  is  fully  exploited  in  the 
synthesis  procedure  for  manufacturing  workcell  design  to  be 
outlined  in  chapter  7.  A  many-to-many  mapping,  called 
controls/controled_by  link,  relates  some  of  the  objects  within  the 
structural     hierarchy    with    objects    within    the    control    knowledge 
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base.  A  structural  object  is  called  an  active  device  if  it  requires 
the  existence  of  a  control  object  to  completely  define  its  behavior. 
There  are  two  types  of  active  devices:  programmable  (e.q.  robots  anc 
numerically  controlled  (NC)  machines)  and  nonprogrammable  (e.a. 
part-feeding  devices).  Programmable  devices  exhibit  flexible 
control  provided  by  a  program.  Nonprogrammable  devices  have  fixeo 
control,  usually  invoked  by  the  occurrence  of  some  event.  Robot 
behavior,  for  example,  is  determined  by  a  program,  where  as  the 
behavior  of  a  gravity  feeder  is  always  the  same  and  initiated  by  an 
event,  namely  the  removal  of  the  first  part  from  the  feeder.  Active 
devices  instantiated  from  the  structural  knowledge  base  also 
require  an  instantiation  of  a  control  object  governing  its  activities. 
A  pair  (active  device,  control  object)  is  termed  an  active   agent. 

In  summary,  the  Structure-Function-Control  (S-F-C)  paradigm 
is  an  extension  to  OSAM*,  a  powerful  object-oriented  semantic 
model.  We  start  with  OSAM*  as  our  base  model  and  then  introduce 
domain  specific  knowledge  in  terms  of  special  semantic 
associations.  These  additional  associations  enable  this  model  to 
better  satisfy  the  complicated  needs  of  the  manufacturing  domain. 
At  the  same  time  the  model  remains  simple  and  intuitive.  The  model 
allows  the  manufacturing  engineer  to  concentrate  on  the  design 
issues  themselves  and  relieves  the  burden  of  dealing  with  the 
details  of  data  modeling. 

The  next  two  chapters  present  the  Structure-Function-Control 
paradigm  in  more  detail. 


CHAPTER  5 
THE  SEMANTIC  DATA  MODEL 


The  S-F-C  paradigm  defines  a  conceptual  level  semantic  layer 
made  of  the  three  knowledge  bases  and  the  mapping  constructs 
among  them.  At  the  logical  level,  the  knowledge  bases  and  their 
classes  can  be  described  in  terms  of  a  data  model  providing  a 
common  set  of  primitive  associations.  In  this  section  we  describe 
this  set  of  associations  which  allow  representation  and 
manipulation  of  structural  and  functional  knowledge.  Within  the 
knowledge  bases,  the  data  model  makes  use  of  a  few  semantically 
rich,  domain-oriented  constructs  not  typically  available  elsewhere, 
along  with  a  subset  of  the  features  provided  by  several  complex 
object-oriented  semantic  data  models  [Smith  and  Smith,  1977;  Hull 
and  King,  1987]. 

As  previously  mentioned,  our  model  treats  structural, 
functional  and  control  objects  individually.  Following  the 
object-oriented  paradigm,  we  generalize  (collect  together)  the 
different  objects  into  classes.  Consequently,  all  object  are 
instances  of  some  class.  For  example,  all  structural  objects  are 
defined  as  instances  of  some  structural  class,  all  functional  objects 
are  instances  of  some  functional  class  and  all  control  objects  are 
instances  of  some  control  class. 
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S-F-C   Object    Definitions 
Formal    definitions    of    the    stmctural,    functional    and    control 
classes  are  given  below. 

Structural    class   definition:  A  structural  class  can  be  formally 
defined  as  a  9  tuple  as  shown  below: 
SC  =  (S.N,  S.I,  S.A,  S.CC,  S.CA,  S.IA,  S.R,  S.LM,  S.PM) 
Where: 

S.N     =         name  of  the  class 
S.i       =         {ii,  \2,  ...,  in},  a  set  of  instances 

S.A     =         proper  subset  of  the  semantic  associations  {G,  A,  I,  P,  C} 
where:         G  is  the  Generalization  association 
A  is  the  Aggregation  association 
I  is  the  interaction   association 
P  is  the  Provides     association 
C  is  the  controiled_by  association 

S.CC   =         {ci,  C2 Cm}  a  set  of  constituent  classes 

S.CA  =         {scai,sca2,...,  scak}  a  set  of  class  attributes,  such  that 
S.CA  =  (La  U  Pa) 

where  La  =  (lai  ,la2,...,  lap)  is  a  set  of  local  attributes 
and    Pa  =  (pai,  pa2,...,  paq)  is  a  set  of  public  attributes 
S.IA    =         {siai,sia2,...,  siak}  a  set  of  instance  attributes,  such  that 
S.IA  =  (LA  U  PA) 

where  LA  =  (LAi  ,LA2,...,  LAp)  is  a  set  of  local  attributes 
and    PA  =  (PAi,  PA2,...,  PAq)  is  a  set  of  public  attributes. 

S.R     =         {sri,  sr2 srt}  a  set  of  rules  for  specifying  knowledge 

associated  with  this  class.  These  rules  specify 
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constraints  on  the  values  for  the  SCA  (class  attributes) 
and  SIA  (instance  attributes).   In  effect,  these  rules 
specify  the  legal  (acceptable)  values  of  the  attributes 
for  a  class. 

S.LM   =         {slmi,  slm2,..,  sIms}  a  set  of  methods  (operations)  that 

can  manipulate  and  change  the  local  and  public  attributes 
of  the  class.  These  operations  are  local  to  the  class  and 
are  visible  only  within  the  class. 

S.PM   =         {spmi,  spm2,..,  spmk}  a  set  of  methods  (operations)  that 
can  manipulate  and  change  the  local  and  public  attributes 
of  the  class.  These  operations  are  visible  to  the  public. 
These  methods  along  with  the  public  class  attributes  and 
public   instance  attributes  constitute  the   interface  to  the 
class. 

Functional   class   definition:  A  functional  class  can  be  formally 
defined  as  a  9  tuple  as  shown  below: 
FC  =  (F.N,  F.I,  F.A,  F.SF,  F.CA,  F.IA,  F.R,  F.LM,  F.PM) 
Where: 

F.N     =         name  of  class 
F.I      =         {ii,  12,  ....  in},  a  set  of  instances 
F.A     =         a  proper  subset  of  the  semantic  associations: 
{G,  A,  F,  n,  R:S} 

where:         G  is  the  Functional  Generalization  association 
A  is  the  Aggregation  association 
F  is  the  Functional  Aggregation  association 
n  is  the  Provided_by  association 
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R:S  is  the  Iteration  association 

F.SF    =         {fi,  f2,...,  fm}  a  set  of  subfunctions 

F.CA  =         {fcai,fca2,...,  fcak}  a  set  of  class  attributes,  sucii  that 
F.CA  =  (La  U  Pa) 

where  La=  (lai  ,la2,...,  lap)  is  a  set  of  local  attributes 
and    Pa  =  (pai,  pa2 paq)  is  a  set  of  public  attributes 

F.IA    =         {fiai,fia2,...,  fiak}  a  set  of  instance  attributes,  such  that 
SIA  =  (LA  U  PA) 

where  LA  =  (LAi   ,LA2,...,  LAp)  is  a  set  of  local  attributes 
and    PA  =  (PAi,  PA2,...,  PAq)  is  a  set  of  public  attributes 

F.R      =        {fn,  fr2,...,  frt}  a  set  of  rules  for  specifying  knowledge 
associated  with  this  class.  These  rules  specify 
constraints  on  the  values  for  the  SCA  (class  attributes) 
and  SIA  (instance  attributes).  In  effect,  these  rules 
specify  the  legal  (acceptable)  values  of  the  attributes 
for  a  class. 

F.LM   =        {flmi,  flm2,..,  fflms}  a  set  of  methods  (operations)  that 

can  manipulate  and  change  the  local  and  public  attributes 
of  the  class.  These  operations  are  local  to  the  class  and 
are  visible  only  within  the  class. 

F.PM   =        {fpmi,  fpm2,..,  fpmk}  a  set  of  methods  (operations)  that 

can  manipulate  and  change  the  local  and  public  attributes 
of  the  class.  These  operations  are  visible  to  the  public. 
These  methods  along  with  the  public  class  attributes  and 
public   instance  attributes  constitute   the   interface  to  the 
class. 
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Control  class  definition:  A  control  class  can  be  formally 

defined  as  a  9  tuple  as  shown  below: 

FC  =  (C.N,  C.I,  C.A,  C.CC,  CCA,  CIA,  CR,  CLM,  CPM) 

Where: 

C.N     =         name  of  class 

CI      =         {ii,  \2,  ....  in},  a  set  of  instances 

C.A     =        a  proper  subset  of  the  semantic  associations: 
{G,  A,  I.  C} 

where:         G  is  the  Generalization  association 
A  is  the  Aggregation  association 
I  is  the  Interaction  association 
r  is  the  Controls  association 

C.CC   =        {ci,  02 Cm}  a  set  of  constituent  classes 

CCA  =         {scai,sca2,...,  scak}  a  set  of  class  attributes,  such  that 
CCA  =  (La  U  Pa) 

where  La  =  (lai   ,la2,...,  lap)  is  a  set  of  local  attributes 
and    Pa  =  (pai,  pa2,...,  paq)  is  a  set  of  public  attributes 

CIA    =        {siai,sia2,...,  siak}  a  set  of  instance  attributes,  such  that 
CIA  =  (LA  U  PA) 

where  LA  =  (LAi   ,LA2,...,  LAp)  is  a  set  of  local  attributes 
and    PA  =  (PAi,  PA2,...,  PAq)  is  a  set  of  public  attributes. 

CR     =         {sri,  sr2,...,  srt}  a  set  of  rules  for  specifying  knowledge 
associated  with  this  class.  These  rules  specify 
constraints  on  the  values  for  the  SCA  (class  attributes) 
and  SIA  (instance  attributes).  In  effect,  these  rules 
specify  the  legal  (acceptable)  values  of  the  attributes 
for  a  class. 
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C.LM   =         {slmi,  slm2,..,  slrris}  a  set  of  methods  (operations)  that 

can  manipulate  and  change  the  local  and  public  attributes 
of  the  class.  These  operations  are  local  to  the  class  and 
are  visible  only  within  the  class. 
C.PM  =         {spmi,  spm2,..,  spmk}  a  set  of  methods  (operations)  that 
can  manipulate  and  change  the  local  and  public  attributes 
of  the  class.  These  operations  are  visible  to  the  public. 
These  methods  along  with  the  public  class  attributes  and 
public   instance  attributes  constitute  the   interface   to   the 
class. 

Structural  Knowledge  Representation 
The  structural  knowledge  data  model  makes  use  of 
Generalization  (G  or  ls_a  relationship),  Aggregation  {A  or  Part_of 
relationship)  and  Interaction  (I)  semantic  associations  among 
classes  as  defined  in  the  OSAM*  data  model  [Su  et  al.,  1989].  We 
found  that  by  using  these  semantic  associations  we  could  model  any 
kind  of  structural  knowledge.  Informal  definitions  of  A,  G  and  / 
were  given  in  chapter  2.  Formal  definitions  of  these  associations 
can  be  found  in  a  paper  by  Su  [Su  et  a!.,  1989]. 

Two  examples  are  given  below  that  illustrate  the  utility  of 
these  associations  in  describing  structural  aspects.  The  first 
example  illustrates  the  recursive  definition  of  classes,  as  well  as 
the  use  of  G,  A  and  /  associations.  The  second  example  illustrates 
how  structural  knowledge  can  be  organized  in  a  hierarchical 
structure,  using  the  G  and  A  associations. 
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Example  1.  Modeling  Parts 

The  first  example  involves  a  workcell  that  manufactures  a  product 
from  a  given  set  of  parts.  The  goal  is  to  design  a  database  which 
will  store  data  about  parts  and  their  relationships.  Parts  can  be 
simple  or  composite.  Simple  parts  are  parts  which  can  not  be 
decomposed  into  other  parts.  Composite  parts  can  always  be 
decomposed  into  subparts.  These  subparts  may  in  turn  be  either 
simple  or  composite.  Therefore,  in  general  the  definition  of  a  part 
is  recursive.  Other  information  about  parts  that  needs  to  be 
captured   includes: 

Phvsical   nrnnerties  of  a   part: 

1 .  Geometry  of  the  part. 

2.  Material  properties  and  manufacturing  constraints: 
Information  about  the  material  of  the  part  is  needed  when 
deciding  about  the  manufacturing  processes.  For  example,  the 
welding  process  depends  on  the  material  properties  of  the 
parts  involved  in  the  welding  operation. 

3.  Inertia  properties  of  a  part:  This  information  may  be  needed 
for  grasping  and  robot  dynamic  analysis. 

4.  Status  of  the  part:  The  status  is  a  boolean  property.  It  is 
false  If  the  part  is  defective,  otherwise  it  is  true. 

5.  Pose  of  the  part  in  the  workcell:  The  location  and  orientation 
of  a  part  in  three  dimensional  space  can  be  represented  by  a 
4-by-4  homogeneous  matrix  with  respect  to  a  universal 
frame. 
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6.  A  part  number:  Every  part  is  uniquely  identified  by  its  part 
number. 

Part  relationships:  Besides  information  about  individual  parts, 
the  system  must  keep  information  on  a  variety  of  relationships 
among  parts. 

1.  Composite  part/simple  part  relation:  At  some  time,  the 
workcell  may  contain  composite  as  well  as  simple  parts.  On 
the  one  hand,  the  system  should  be  able  to  distinguish 
between  simple  and  composite  parts.  On  the  other  hand,  it 
should  be  able  to  refer  to  a  composite  part  as  a  unit,  since  a 
composite  part  is  still  a  part.  In  addition,  when  two  parts  are 
joined  together,  they  no  longer  exist  as  separate  parts. 
Therefore,  a  new  part  is  generated  while  the  parent  parts  are 
removed  from  the  database. 

2.  Liaisons  between  parts:  A  liaison  is  defined  to  be  an 
operation  for  joining  two  parts  (screw,  weld,  etc.). 

3.  Relative  positions  of  parts:  For  a  composite  part,  the  position 
and  orientation  of  each  subpart  is  specified  by  a  4-by-4 
homogeneous  transformation  matrix.  This  matrix  defines  the 
position  and  orientation  of  the  local  coordinate  system  for  the 
subpart  (body  attached  frame)  with  respect  to  a  frame  local 
to  the  composite  part. 

The    semantic    diagram    of    the    parts    database    is    shown    in 
Figure  3.     We  define  an  object  class  called  PART.     This  object  class 
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models  the  general  notion  of  composite  part.  The  class 
SIMPLE_PART  is  a  subclass  of  PART.  Through  this  generalization 
hierarchy  we  model  real  world  objects  (simple  or  composite  parts). 
For  every  real  world  object,  there  must  exist  a  corresponding 
instance  of  either  the  PART  or  SIMPLE_PART  classes.  Note  that  a 
simple  part  is  a  special  case  of  composite  part,  in  that  its 
"parent_part"  and  "subparts"  attributes  are  null.  In  addition,  it  has 
an  extra  attribute  which  models  its  geometry,  namely,  "CAD_model." 
The  object  class  PART,  defines  a  set  of  attributes  which  are 
inherited  by  its  subclass.     These  attributes  are: 

1 .  Part   name:  Gives  a  name  to  a  part  instance.     This  attribute 
together  with  Part_number  serves  as  the  key. 

2.  Part   number:  Distinguishes  among  the  part  instances  with  the 
same  Part_name. 

3.  Status:  States  if  the  part  is  defective  or  not. 

4.  Pose:  Is  a  4-by-4  homogeneous  transformation  matrix. 

The  object  class  CAD_MODEL  defines  the  geometry,  color, 
visibility,  etc.  of  simple  parts.  It  acts  as  a  domain  for  the  attribute 
"Has_model"  of  the  class  SIMPLE_PART.  The  attribute  "Has_moder' 
cannot  be  null,  which  implies  that  every  simple  part  must  have  a 
geometric  description.  Notice  that  the  mapping  between  the 
instances    of    SIMPLE_PART    and    CAD_MODEL    is    not    necessarily 


40 


SUBPARTS 


WELDING 


BOLTING 


OTHERS 


Figure  3.  Parts/Liaisons  knowledge  base  (S-diagram). 


one-to-one.  This  means  that  simple  parts  with  the  same  physical 
properties  have  the  same  value  for  the  "Has_model"  attribute  (i.e., 
point  to  the  same  CAD_MODEL  instance). 


41 
Figure  4  shows  the  CAD_MODEL  class  in  more  detail.    As  seen 
from  the  semantic  diagram,  the  geometry  of  a  simple  part  is  defined 
by  a  set  of  faces  (3D  polygons).    In  turn,  the  faces  are  described  by  a 
set  of  edges  (3D  lines).    Edges  are  represented  by  3D  points. 

In  our  design  the  geometry  of  a  composite  part  is  defined 
recursively  through  the  geometry  of  its  subparts  and  some 
additional  information  on  the  positional  relationship  of  its 
sub-parts.  Positional  relationships  are  captured  by  the  "Pose" 
attribute  of  the  SIMPLE_PART  class  and  are  discussed  below. 

Note  that  the  attribute  "Pose,"  defined  in  the  class  PART  and 
inherited  by  the  class  SIMPLE_PART,  has  different  interpretations 
depending  on  the  particular  part. 

1.  For  an  instance  of  SIMPLE_PART  which  is  not  a  subpart  of 
some  composite  part,  the  pose  refers  to  the  location  and 
orientation  of  the  part  with  respect  to  the  world  coordinate 
frame. 

2.  For  an  instance  of  the  class  SIMPLE_PART,  which  is  a  subpart 
of  some  composite  part,  the  attribute  "Pose"  refers  to  the 
location  and  orientation  of  the  part  with  respect  to  the 
composite  part  coordinate  frame. 

These  semantics  are  enforced  by  rules  defined  in  the 
SIMPLE  PART  class. 
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Figure  4.  The  Parts  geometric  model. 
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The     PART     object     class     participates     in     an     interaction 
association.      This   interaction   association   class   ASSEMBLED_WITH, 
models  the  following  three   relationships  among   parts: 

1.  Any  number  of  simple  parts  can  be  joined  together  to  form  a 
composite   part. 

2.  Any  number  of  composite  parts  can  be  joined  with  any  number 
of  simple  parts  to  form  a  composite  part. 

3.  Any  number  of  composite  parts  can  be  joined  to  any  number  of 
composite  parts  to  form  a  composite  part. 

The  ASSEMBLED_WITH  class  defines  the  attribute  "Assembly 
operation."  This  new  attribute  draws  its  values  from  the  object 
class  ASSEMBLY_OPERATION.  In  turn,  the  object  class 
ASSEMBLY_OPERATION  defines  a  generalization  hierarchy  which 
provide  additional  information  about  the  different  kinds  of  assembly 
operations. 

Example  2.  Workcell  Components  Librarv 

This  second  example  presents  the  design  of  a  database  which  we  use 
as  our  manufacturing  workcell  components  library.  This  database 
stores  information  that  is  usually  available  in  numerous  workcell 
devices   manufacturing  catalogs. 

In  Figure  5  an  example  of  structural  knowledge,  the 
components  library,  is  shown.  This  figure  is  not  intended  to  provide 
a  comprehensive  classification  of  the  components  found  in 
manufacturing  workcells,   but  merely  to   serve  as   illustration  for  the 
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purpose  of  this  example.  The  notation  used  in  the  semantic  schemas 
throughout  this  dissertation  is  based  on  the  OSAM*  S-diagrams  [Su 
et  al.,  1989],  with  some  extensions  and  minor  modifications.  Using  a 
Generalization  (G)  association  the  workcell  equipment  is  initially 
classified  as  transportation  equipment,  process  equipment  or 
auxiliary  equipment.  Transportation  equipment  is  further  classified 
into  robots,  mobile  robots  and  conveyors.  Continuing  the  traversal 
of  the  G  hierarchy,  a  robot  can  belong  to  one  of  the  Puma,  C.  Milacron 
or  Adept  families.  As  a  last  refinement,  the  particular  robot  models 
are  given  at  the  leaf  nodes  of  the  G  hierarchy.  Similar  G  hierarchies 
are  shown  for  the  process  equipment  and  auxiliary  equipment 
classes.  The  components  library,  expressed  as  a  semantic  schema, 
provides  a  taxonomy  of  equipment  with  multiple  abstraction  layers 
(the  so-called  ls_a  hierarchy)  and  conveys  structural  information 
about  the  entity  objects  at  the  leaves  of  the  schema.  For  example,  a 
robot,  whatever  its  manufacturer  and  its  model,  is  an  aggregation  of 
a  controller  and  a  manipulator.  This  information  is  captured  through 
the  Aggregation  (A)  association  on  the  robot  class  and  is  inherited 
downwards  through  the  G  hierarchy.  Entity  objects  also  embody  a 
number  of  methods  and  attributes,  not  illustrated  in  Figure  5,  such 
as  the  geometrical  and  dimensional  attributes  and  the  graphical  and 
kinematics  methods  required  to  display  and  simulate  the  objects 
themselves. 

The  construction  of  the  structural  hierarchy  is  clearly  the  job 
of  a  knowledge  engineer.  All  the  information  captured  by  the 
structural     hierarchy     is     readily     available     from     the     different 
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Workcell 
component 


Transportation 
equipment 


Process 
equipment 


Auxiliary 
equipment 


Figure  5.    An  example  of  a  structural  knowledge  schema. 


manufacturers  in  workcell  component  catalogs.  The  geometric 
descriptions  of  workcell  components  need  to  be  created  using  a 
computer  aided  design  tool.     Developing  the  kinematics  and  dynamics 
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methods  for  the  workcell  components  may  be  problematic  since 
many  manufacturers  consider  such  things  as  company  secrets.  In 
these  cases,  the  kinematics  and  dynamics  routines  need  to  be 
redeveloped  based  on  the  available  information  found  in  a  variety  of 
excellent  textbooks  and  papers  on  the  subject. 

A  final  note  on  this  subject  is  that  the  dynamics  and 
kinematics  routines  for  the  different  workcell  components,  although 
themselves  describing  dynamic  activities,  could  be  stored  as  static 
attributes.  These  routines,  stored  in  the  form  of  executable  code, 
can  be  retrieved  from  the  database  and  executed  at  simulation  time. 
Only  at  this  time  do  they  exhibit  their  dynamic  behavior. 


Functional  Knowledge  Representation 
To  express  the  dynamic  information  inherent  in  the  functional 
description,  additional  semantic  mechanisms,  besides  the  static 
Generalization  and  Aggregation  associations,  are  required.  In 
particular,  in  the  functional  domain  we  need  to  be  able  to  capture 
the   following   semantics: 

Functional     decomposition:      In  general,  a  function,    H,  can   be 

decomposed  into  a  set  of  subfunctions  SH  =  {fi ,  f2 fn},  which 

describe  H  in  a  greater  detail. 

Sequencing  of  subfunctions:     In  general,  ordering  constraints  need 
to  be  specified  among  subfunctions,  fi,  fa,  ...,  fn,  of  a  function,  H. 
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This     is     necessary    so     that    the     ordered     execution     of    the 
subfunctions,   fi,  f2,  ....  fn,  is  equivalent  to  the  execution  of  H. 

Optional    subfunctions:       Manufacturing    processes    may    include 
required  and  optional  steps.     This  means  that  given  a  function,  H, 

and  its  subfunctions,  SH  =  {fi ,  f2 fn},  a  member  of  SH,  say  fj, 

could  be  the  NULL  function. 

Semantic  Associations   in  the   Functional   Domain. 
In    order   to    capture    the    above    semantics   we    introduce    the 
following    semantic   associations: 

Aaareaation  and  Functional  Aaareaation 

The  Aggregation  association  in  the  functional  domain  carries 
special  semantics.     It  is  defined  as  follows: 

Definition:  Given  a  set,  SH,  of  subfunctions  of  a  function,  H 
(functions  relating  to  H  with  the  Part_of  relation),  such  that  SH  = 
{fl ,  f2."--fn},  then  this  set  defines  an  Aggregation  association  iff 
the  function  H  can  be  carried  out  by  executing  fi ,  f2,  ...,  fp  in  any 
order. 

Note  that  the  definition  of  the  Aggregation  association 
imposes  no  constraints  on  the  order  of  subfunction  execution. 
Therefore,  the  Aggregation  association  allows  for  the  possibility  of 
concurrency. 
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The  Aggregation  association,  as  defined  above  does  not 
explicitly  provide  any  sequencing  information.  The  so-called 
Functional  Aggregation  (F),  originally  proposed  by  Cornelio  [Cornelio 
et  a!.,   1990;  Cornelio  and  Navathe,   1990],  seems  to  fulfill  this  neea. 

Cornelio  proposed  the  Functional  Aggregation  which  he  defines 
as  a  set  of  subfunctional  objects  together  with  a  functional 
interconnection  network  (FIN).  The  functional  interconnection 
network  is  basically  a  directed  graph  which  fully  specifies  the 
execution  ordering  of  the  participating  subfunctions.  In  effect,  the 
FIN  represents  one  particular  manufacturing  plan  out  of  a  set  of 
valid  manufacturing  plans.  For  our  purposes  the  Functional 
Aggregation  as  defined  by  Cornelio  is  a  bit  restrictive.  It  requires 
that  a  strict  ordering  of  subfunction  execution  be  specified,  thus 
eliminating  the  possibility  of  representing  many  alternative 
manufacturing  plans  using  the  Functional  Aggregation  association. 

It  is  our  opinion  that  the  functional  schema  should  be  a 
repository  of  functional  knowledge.  Therefore,  our  goal  is  to  define 
the  functional  schema  so  it  captures  knowledge  about  a  set  of  vand 
(or  recommended)  manufacturing  plans.  It  should  then  be  the 
manufacturing  engineers  responsibility  to  select  one  or  more  of 
these  plans  for  evaluation  and/or  implementation.  This  selection 
process  is  discussed  in  greater  detail  in  a  later  chapter. 

For  the  above  reasons  we  define  the  Functional  Aggregation  (F) 
as   follows: 

Definition:  Given  an  ordered  set,  SH,  of  subfunctions  of  a 
function,    H    (relating    to    H    with    the    Part_of    relation),    such    that 
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SH  =  {fi,  f2,...,fn},    then  this  set  defines  a  Functional  aggregation     iff 
the  function,   H,  is  carried  out  by  executing  fi ,  iz,  ■■■,  fn  in  the  given 
order. 

Note  the  following: 

1.  A  strict  sequential  ordering  is  defined  on  all  subfunctions 
of  a  Functional  Aggregation.  This  makes  the  Functional 
Aggregation  a  very  simple  and  unambiguous  association  . 

2.  The  Functional  Aggregation  can  be  explicitly  represented 
on  the  semantic  diagrams.  As  a  convention,  the  execution 
of  the  sub-functions  follows  a  left  to   right  ordering. 

3.  The  total  participation  constraint  is  not  imposed  on 
subfunctions  in  a  Functional  Aggregation.  This  means  that 
the  manufacturing  engineer  can  eliminate  subfunctions. 
This,  by  itself,  suggests  that  the  functional  semantic 
schema  can  represent  a  set  of  possible  manufacturing 
plans. 

4.  Partial  orderings  of  any  complexity  can  be  defined  with 
subfunctions.  These  partial  orderings  can  be  expressed 
using  an  arbitrary  combination  of  Aggregation  and 
Functional  Aggregation  associations.  (A  proof  of  this 
claim  is  presented  later).  As  discussed  by  Fox  and  Kempf 
[Fox  and  Kempf,  1987],  partial  orderings  are  capable  of 
representing  a  set  of  manufacturing  plans. 
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The  observation  about  the  total  participation  constraints 
needs  a  little  clarification.  In  OSAM*  and  many  other  models, 
integrity  constraints  can  be  imposed  on  an  Aggregation  association. 
These  constraints  can  take  several  forms.  One  such  constraint 
which  is  of  great  importance  here,  is  the  so  called  total 
participation  constraint.  This  constraint,  when  imposed  on  an 
aggregate,  restricts  its  value  to  be  non-null. 

The  total  participation  constraint,  when  defined  on  an 
aggregate  (i.e.,  subfunction)  of  an  A  or  F  association,  forces  this 
subfunction  to  be  non-null.  Therefore,  the  total  participation 
constraint  captures  the  semantics  of  a  mandatory  subfunction.  In 
addition,  a  subfunction  without  any  constraints,  is  considered  to  be 
an  optional  subfunction  and  can,  therefore,  be  omitted  from  the  final 
manufacturing  plan   (i.e.,   instantiated  with  the  null  function). 

In  general,  manufacturing  procedures  usually  contain  a  large 
number  of  mandatory  subfunctions  and  only  a  few  optional  ones. 
This  is  in  contradistinction  with  other  database  domains  where 
total  participation  constraints  are  rare.  For  this  reason,  as  a 
convention  in  a  semantic  diagram  we  only  mark  the  optional 
subfunctions.  This  keeps  the  semantic  diagram  uncluttered  and 
requires  less  work  from  the  user.  On  the  semantic  diagram  an 
optional  function  is  marked  with  a  capital  'O'  which  is  an 
abbreviation   for  optional. 

The  observation  about  partial  orderings  needs  a  little  more 
clarification,  also.  Consider  the  function  "Populate  PCB"  in  Figure  6. 
This  function  can  be  accomplished  by  executing  its  subfunctions, 
which  are  Feed  components,  Feed  board,  Populate  board  and  Unload 
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board.     Notice  that  more  than  one  valid  execution  ordering  can  exist 
among  these  subfunctions.     In  fact,  there  is  a  set  of  three  possible 
such  orderings  which  are  as  follows: 

1.  "Feed  components" 
followed  by  "Feed  board" 
followed  by  "Populate  board" 
followed  by  "Unload  board," 

2.  "Feed  board" 

followed  by  "Feed  components" 
followed  by  "Populate  board" 
followed  by  "Unload  board"  or 

3.  "Feed  board"  and  "Feed  components"  done  concurrently 
followed  by  "Populate  board" 

followed  by  "Unload  board." 

In  order  to  be  able  to  represent  all  three  valid  subfunction 
orderings  in  the  functional  schema  diagram,  we  make  use  of  a 
combination  of  A  and  F  associations.  A  combination  of  A's  and  F's 
can  explicitly  represent  the  ordering  constraints  among  these 
subfunctions  and,  therefore,  can  capture  the  semantics  of  a  partial 
order  (PO).     The  definition  of  a  partial  order  is  given  below: 

Definition [BerztiSS. 1975]:    a    reflexive,    antisymetric    and 

transitive  relation  in  a  set  A  is  a  partial  order(ing)  in  the  set  A.     If  R 
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is  a  partial  order  in  A,  the  ordered  pair  <A,R>  is  a  partially    ordered 
set. 

A  relation  R  is  reflexive  if  for  any  a  e  A,  aRa  is  true. 

A  relation  R  is  antisymetric  if  for  any  a,  b  €  A,  aRb  and  bRa 

imply  a=b  for  all  a,  b  e  A. 

A  relation  R  is  transitive  if  for  any  a,b,c  e  A,  aRb  and  bRc 

imply  aRc  for  all  a,  b,  c  e  A. 


Figure  6.  Functional  semantic  schema    capturing  a  partial  order 

relation. 


Another  example  is  given  here  in  order  to  clarify  a  special 
case  of  the  use  of  the  semantic  diagrams.  Assume  that  the 
decomposition     of    a     function     H     calls     for     the     execution     of 
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subfunctions  si  followed  by  S2  followed  by  si  again.  In  order  to 
emphasize  that  si  consists  of  a  single  operation,  the  representation 
shown  in  Figure  7  can  be  used.  The  subfunctions  s1  and  s2  are  drawn 
only  once.  Then  following  our  convention  that  calls  for  left  to  right 
execution,  we  draw  three  links  leaving  H.  The  leftmost  ends  at  si, 
the  middle  ends  at  S2  and  the  rightmost  crosses  the  middle  link  and 
ends  back  at  si . 


Figure  7.  Semantic  diagram  showing  sequence  si-S2-si 


Summarizing,  an  Aggregation  association  describes  a  function 
in  terms  of  its  subfunctions,  while  it  imposes  no  constraints  on  the 
ordering  of  its  subfunction  execution.  On  the  other  hand,  the 
Functional  Aggregation,  besides  describing  a  function  in  terms  of  its 
sub-functions  (thus  capturing  the  Part_of  semantics),  also  express  a 
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sequential  ordering  constraint  on  subfunction  execution.  The 
ordering  constraint  is  determined  by  the  nature  of  the  described 
function.  In  order  to  explicitly  represent  a  set  of  manufacturing 
plans  in  the  functional  semantic  schema,  a  set  of  arbitrary 
combinations  of  Aggregations  and  Functional  Aggregations  can  be 
used.  On  the  semantic  diagram  functions  marked  with  'O'  are 
considered  to  be  optional  (i.e.,  no  participation  constraint  is 
defined). 

Functional    Generalization 

In  a  highly  dynamic  domain  such  as  manufacturing,  a  function 
(manufacturing  operation),  may  take  different  forms  at  different 
times.  For  example,  the  prepare  component  function  of  Figure  8,  may 
take  the  form  of  either  prepare  radial,  prepare  axial  or  prepare  IC, 
depending  on  the  kind  of  electrical  component  to  be  processed.  From 
the  above  discussion  we  see  that  there  is  a  need  for  some 
association  that  can  express  the  semantics  of  selection.  This 
association  should  capture  and/or  enforce  the  following  semantics: 

1.  Constituent  functions  provide  the  same  kind  of  functionality 
as  the  original  function,  but  maybe  in  a  more  specialized 
form.  Therefore,  the  constituent  functions  are  ls_a  related 
to   the  original   function. 

2.  The  constituent  functions  (selection  alternatives)  should  be 
distinct   (i.e.,    satisfying   set  exclusion). 

3.  Some  selection  criteria  should  be  defined. 


55 


A  closer  look  at  the  selection  semantic  association  reveals 
some  similarities  with  the  Generalization  association  as  defined  in 
the  structural  domain.  In  fact,  from  the  database  point  of  view,  the 
selection    association,    as    defined    here,    can    be    viewed    as    a 


Conditions: 

c1 :  part  =  radial 
c2:  part  =  axial 
c3:  part  =  IC 


Figure  8.     Functional  generalization  association. 


Generalization  association  satisfying  the  set  exclusion,  plus  some 
other  constraints.  These  additional  constraints  are  a)  the 
association  is  defined  on  functions  and  b)  the  instantiation  of  the 
class  corresponding  to  this  association  is  guided  by  the  selection 
criteria. 

Due     to     the     many     similarities     of     selection     and     the 
Generalization   association,    the    Generalization    association    will 
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serve   as   a   starting   point.      The   semantics   of  the   Generalization 
association  are  then  augmented  to  satisfy  the  selection  semantics. 

Within  the  functional  knowledge  data  structure,  the  modified 
Generalization  association  captures  additional  special  semantics.  It 
expresses  alternatives  and  conditional  execution  of  subfunctions. 
This  new  semantic  association  we  call  Functional  Generalization. 
On  the  semantic  diagram  the  Functional  Generalization  is  denoted 
with  the  symbol  G  as  in  Figure  8. 

Iteration     Association 

A  new  construct,  called  Iteration  Association  (R:S),  is  provided 
within  the  functional  knowledge  data  model  for  notational 
conciseness  and  abstraction  purposes.  The  mnemonic  R  (for  repeat) 
is  used  here  instead  of  /  to  avoid  any  confusion  with  the  Interaction 
association  /  provided  by  OSAM*.  The  Iteration  association  imposes 
an  ordering  with  respect  to  time  on  all  the  instances  of  a  functional 
class  and  calls  for  the  repeated  instantiation  of  identical 
subfunctions  at  a  lower  abstract  level.  This  association  enhances 
the  modeling  power  by  providing  an  equivalent  to  the  loopmg 
primitive  of  programming  languages.  For  instance,  the  function 
populate  printed  circuit  board  is  related  to  the  function  process 
component  by  an  Iteration  association  since  the  repeated  execution 
of  the  latter  function  is  required  to  accomplish  the  former  one.  The 
iteration  set  S  is  defined  to  be  an  arbitrary  ordering  relation  on  the 
set  of  all  the  instances  of  the  participant  functional  class.  In  our 
particular  example  let  us  assume  that  the  instances  of  the 
functional   class  prepare    component  are  the  following:  Prepare  R1, 
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prepare  R2,  prepare  IC1  and  prepare  CI  (where  R  is  a  resistor,  IC  is 
an  integrated  circuit  and  C  is  a  capacitor).  Under  the  assumption 
that  the  same  tool  could  be  used  to  process  both  the  resistors  and 
capacitors,  but  a  tool  change  is  required  to  process  the  ICs,  an 
efficient  assembly  plan  may  call  for  the  following  sequencing: 
S  =  (Prepare  R1,  Prepare  R2,  Prepare  CI,  Prepare  IC1).  This  sequence 
consists  of  the  Iteration  set  S  associated  with  the  Iteration 
association  (see  Figure  9).  As  a  convention,  on  the  semantic 
diagram,  the  Iteration  association  is  represented  by  a  link  labeled  as 
R:S  where  R  denotes  the  Iteration  association  and  S  is  the  iteration 
set. 

Provides/Provided    bv   Association 

Finally,  the  Provides/Provided_by  association  is  introduced  to 
support  the  integration  of  the  structural  and  functional  knowledge. 
This  association  consists  of  explicitly  named  links  that  represent 
relationships  as  in  the  E-R  model  [Chen,  1976]  and  connects  the 
structural  and  functional  knowledge  descriptions.  These 
bidirectional  one-to-many  links  are  represented  on  the  semantic 
diagram  by  using  two  distinct  labels.  The  symbol  P  labels  links  that 
point  away  from  a  structural  class  (see  Figure  5)  and  terminate  on 
one  or  more  functional  classes.  P  links  capture  the  semantics:  "An 
instance  of  a  structural  object  belonging  to  this  class  may  be  able 
to  provide  the  following  classes  of  functions."  This  relationship  is 
"one-to-many"  since  one  structural  device  may  be  able  to  provide 
more  than  one  function.  The  n  labeled  links  point  away  from  a 
functional    class    (see    Figure    10)    and    terminate    on    one    or    more 
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structural  classes  with  the  semantics:  "A  function  within  this  class 
is  provided  by  the  instances  of  the  following  classes  of  structural 
objects."  Again  this  relationship  is  "one-to-many,"  since  this 
function  could  possibly  be  provided  by  more  than  one  structural 
object. 


Populate 
board 


R:S 


Process 
component 


Iteration  set: 

S=  (Prepare  R1, 

Prepare  R2, 

Prepared, 

Prepare  IC1) 

Figure  9.     Iteration  association. 


The  Provides/Provided_by  association  not  only  integrates  the 
structural  and  functional  knowledge,  but  also  provides  a  powerful 
foundation  for  an  intelligent  suggestion  system.  This  system  could 
act  as  an  "Intelligent  Assistant"  to  the  workcell  designer  by 
providing  relevant  information  that  is  otherwise  available  only 
through    numerous  component  catalogs.      The   "Intelligent  Assistant" 
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system   would    make   use   of   the    Provides/Provided_by  links  to 
retrieve   and   present  the  workcell   designer  with   a   list  of   functions 
that  particular  workcell  components  can   provide. 

A  formal  definition  of  the  P,  n  links  is  given  below: 

Given:  S  =  {si,  S2 sn},  a  set  of  structural  objects,  and 

F  =  {fi,  h,  •••,  fm},  a  set  of  functional  objects, 
then  the  Provides/Provided_by  association  defines  two 
functions  between  S  and  F  as  follows: 

Provides  is  a  mapping  P, 
P  :  S  ^  2^  and 


Provided_by  is  a  mapping  n, 
n  :  F  ^  2S. 


In  other  words,  P{si)  =  {fn,-.,fp},  which  means  that  the  Provides 
function  applied  on  structural  object  Sj  returns  a  set  of  functions 
{fn.--.fp}-  These  are  functions  that  the  workcell  device  Sj  is  capable 
of  providing.  On  the  other  hand,  n(fj)  =  {Sk,..,Sq},  which  means  that 
the  Provided_by  function  applied  on  fj  returns  a  set  of  structural 
objects  (workcell  devices)  {Sk,..,Sq}.  This  set  of  structural  objects 
specifies  the  workcell  devices  that  can  provide  the  function  fj. 

Based  on  the  above  definitions  a  constraint  for  a  design  to  be 
complete   is  the  following: 

Design  constraint:  If  fj  e  F  then  there  should  exist  an  Sj  such 
that  P(Sj)  =  Uf,  Uf  c  2^  and  fj  e  Uf. 
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A  design   constraint,   therefore,   dictates  that  for  each   function, 
fi,    included    in   the   design    specification,    there    exist   some   workcell 
component,    sj,  that  can  provide  this  function. 

The  Functional  Knowledge  Representation 
We  distinguish  two  kinds  of  functional  knowledge.  First,  there 
is  knowledge  about  individual  atomic  manufacturing  functions. 
These  are  functions  that  could  be  accomplished  by  a  single  workcell 
device.  An  example  of  an  atomic  function  is  Tin  resistor  leads.  We 
term  these  as  atomic  functions.  The  second  kind  of  functional 
knowledge  is  knowledge  about  manufacturing  procedures.  A 
manufacturing  procedure  is  an  ordered  set  of  atomic  functions  which 
when  executed  produces  some  desired  result  (usually  the 
manufacture  of  some  product).  An  example  of  a  manufacturing 
procedure  is  Prepare  and  Insert  IC  Into  PCB.  Information  describing 
manufacturing  procedures  can  be  represented  using  a  semantic 
functional  schema,  as  previously  discussed. 

Product  creation,  in  general,  consists  of  two  substeps.  These 
are  1)  design  of  the  product  itself  and  2)  design  of  the 
manufacturing  process  that  can  produce  the  product.  Usually  several 
iterations  of  these  substeps  are  necessary  in  order  to  achieve  a 
satisfactory  solution  (i.e.,  an  acceptable  product  and  an  acceptable 
manufacturing  process).  The  two  substeps,  in  general,  are  not 
independent  since  changes  in  one  necessitate  changes  in  the  other. 
For  example,  to  simplify  some  manufacturing  procedure  required  to 
produce  a  part  may  require  that  the  original  part  design  be  modified. 
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This    section    discusses    step    2,    namely    the    generation    of    the 
manufacturing  procedure  given  a  product  design  specification. 

Initially,  a  high  level  specification  of  the  manufacturing 
process  needs  to  be  formulated.  This  may  be  a  very  general 
statement  such  as:  "Prepare  electrical  components  for  insertion  into 
PCB."  We  call  this  general  statement  the  primary  function  of  the 
manufacturing  process.  To  develop  a  detailed  manufacturing  plan  we 
start  with  this  primary  function  and  recursively  decompose 
functions  into  a  set  of  subfunctions.  When  decomposing  a  function 
into  subfunctions  the  following  constraint  should  be  satisfied:  the 
execution  of  the  subfunctions  should  result  in  accomplishing  the 
decomposed  function.  According  to  our  model,  the  decomposition  is 
captured  using  either  the  Aggregation,  Functional  Aggregation. 
Functional  Generalization  or  Iteration  association.  This  recursive 
functional  decomposition  procedure  results  in  a  functional  schema 
which  in  fact  captures  knowledge  about  a  set  of  manufacturing  plans 
capable  of  providing  the  original  function.  The  functional 
decomposition  terminates  when  all  leaf  nodes  correspond  to  atomic 
functions. 

The  semantic  network  shown  in  Figure  10  is  an  example  of  a 
functional  knowledge  schema.  In  this  schema  the  function  Populate 
Printed  Circuit  Board  is  expressed  in  terms  of  its  subfunctions.  As 
previously  discussed,  within  the  functional  knowledge  domain  the 
Generalization  association  expresses  alternatives  and  conditional 
execution  of  subfunctions.  The  Aggregation  association  describes 
functions  in  terms  of  the  required  subfunctions  without  ordering 
constraints.     The  Functional  Aggregation  adds  ordering  semantics  to 
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SL:  StraJQhten  Leads 
SCL:  Shape/Cut  Leads 
CL:  Clean  Leads 
TL:  Tin  Leads 
ETO:  Electrical  Test  Ottiers 
ET:  Electrical  Test  IC 
OT:  Orientation  Test  IC 
INS:  Component  Insertion 
BLB:  Bend  Leads  Below 


Figure  10.  An  example  of  a  functional  knowledge  schema. 
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the  Aggregation.      In  our  graphical   notation,   a  left-to-right  execution 
ordering  is  assumed  as  a  convention.     Functional    Aggregations  and 
Aggregations    can  be  nested  in  any  way,  thus  providing  the  means  for 
expressing   complex   partial   ordering   relationships. 

Referring  to  the  example  illustrated  in  Figure  10  the  Iteration 
association  fulfills  the  goal  of  isolating  the  abstraction  at  the 
individual  component  level  from  the  abstraction  at  the  board  level. 
The  Functional  Aggregation  association,  according  to  our  experience, 
appears  to  significantly  enhance  the  overall  semantic  modeling 
power  in  the  functional  knowledge  modeling  domain,  such  that  its 
role  cannot  be  replaced  by  other  constructs  or  combination  of  them 
as  defined  in  the  most  common  semantic  data  models. 

One  of  our  goals  is  to  provide  the  workcell  designer  with  a  tool 
that  simplifies  the  equipment  selection.  This  tool  should  act  as  an 
Intelligent  Assistant  (lA)  to  the  workcell  designer  during  the 
equipment  selection  process.  The  lA  should  be  able  to  suggest 
particular  workcell  components  that  satisfy  functional 
requirements  of  the  design.  For  example,  if  the  designer  is 
considering  the  transportation  of  the  different  parts  inside  the 
workcell  he  should  be  able  to  ask  the  lA  for  a  list  of  equipment  that 
can  perform  this  function.  Recall  that  the  nodes  of  the  functional 
schema  have  links  to  a  library  of  workcell  components.  Specifically, 
nodes  in  the  functional  semantic  schema  point  to  workcell 
component  models  (which  are  stored  in  the  workcell  component 
library),  that  are  capable  of  providing  the  particular  function 
specified  by  the  functional  node. 
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The  creation  of  a  functional  subschema  is  the  job  of  a 
knowledge  engineer.  The  knowledge  engineer  may  need  to  consult 
with  manufacturing  engineers  that  are  experts  in  the  field, 
investigate  the  literature  (research  papers  and  reports)  and  consult 
manufacturing  procedures  handbooks  and  probably  other  sources,  in 
order  to  be  able  to  design  a  functional  subschema  corresponding  to 
some  manufacturing  procedure.  Note  that  the  development  of  a 
functional  subschema  is  not  an  exact  scientific  process.  It  relies 
heavily  on  the  collection  of  heuristic  knowledge  and  past  experience 
of  the  manufacturing  experts.  In  spite  of  this,  tools  may  be 
developed  that  can  help  and/or  augment  these  experts.  Chapter  6 
presents  a  theory  which  is  intended  to  be  used  as  the  basis  for  one 
such  tool.  This  tool  will  automate  the  generation  of  manufacturing 
procedure  plans. 
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CHAPTER  6 
ALGEBRA  OF  FUNCTION  SEQUENCING  -AN  AXIOMATIC  THEORY 


In  the  previous  chapter  we  discussed  the  functional  domain 
schema  and  mentioned  that  its  construction  is  the  knowledge 
engineer's  job.  From  a  practical  point  of  view,  the  functional 
semantic  schema  should  be  a  repository  of  knowledge  about 
manufacturing  functions  and  procedures  that  we  wish  to  recommend 
for  practice  by  our  users.  This  knowledge  comes  from  different 
sources  such  as  engineering  design  handbooks,  human  experts, 
research,  experimental  findings,  etc.,  and  represents  expertise  and 
experience  acquired  throughout  the  years.  The  functional  schema 
ideally  should  capture  knowledge  which  has  been  proven  correct  and 
reliable.    As  such,  it  should  be  used  as  a  'How  to'  guide. 

On  the  other  hand,  the  idea  of  automatically  generating  this 
functional  schema  is  an  interesting  one.  This  idea  has  been 
researched  for  many  years  and  consists  of  the  well  known  and 
classical  problem  of  task  planning. 

The  two  most  difficult  problems  that  arise  in  task  planning 
are:  a)  the  combinatorial  explosion  of  task  alternatives  and  b)  the 
task-sequence  representation  problem.  Combinatorial  explosion  is  a 
classical  problem  in  the  field  of  artificial  intelligence.  It  refers  to 
a  phenomena  in  which  the  number  of  alternatives  to  be  investigated 
(in   this   case,    candidate    manufacturing    plans)    grows   exponentially 
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with  respect  to  the  number  of  states  (parts)  involved.  The  task 
sequence  representation  problem  received  a  lot  of  attention  by  many 
researchers.  Different  methods  have  been  proposed  in  the  literature 
for  solving  this  problem  such  as  AND/OR  graphs  [De  Mello  and 
Sanderson,  1986],  partially  ordered  set  diagrams  [Fox  and  Kemph, 
1987],  DTP  trees  [Ayoub  et  al.,  1988]  and  a  template  based  graphical 
representation  [De  Fazio  and  Whitney,  1987]. 

In  this  chapter  we  present  a  different  approach  to  this 
problem.  We  develop  an  new  axiomatic  theory  which  we  call  the 
Algebra  of  Function  Sequencing.  This  algebra  establishes  a  method 
for  representing  task  sequences  (an  attempt  to  solve  the 
representation  problem)  and  defines  the  rules  which  allow  us  to 
manipulate  these  sequences. 

The  Algebra  of  Function  vSeouencing 
We  first  present  a  few  definitions  and  clarification   notes  with 
respect  to  our  representation.     We  then  proceed  to  formally  define 
the  proposed  algebra. 

In  the  definitions  that  follow  below,  we  use  the  square  bracket 
symbols,  '['  and  ']',  to  group  functions  together.  The  use  of  these 
symbols  carry  special  semantics.  For  instance,  the  use  of  the 
brackets  in  an  expression  such  as  fi  0  [f2  ®  fa],  defines  the  way  the 
expression  is  pictorially  represented  in  a  functional  diagram.  By  no 
means  does  it  imply  that  the  subexpression  inside  the  brackets 
should  be  evaluated  first.  The  order  of  execution  is  dictated  by  the 
axioms    (which    are    presented    later)    and    not    by    the    way    the 


67 
expression   is  written.     Figure   11    presents  different  examples   in  an 
attempt  to  further  clarify  the  use  of  square  brackets. 


fi-[f2*^3^       <=>  f. 


[f^M^ieif^.fg]     <=^ 


^  ^2 


*2  ^3 


U  ^2      ^..  f 


Figure  11.  Usage  of  the  square  brackets 
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We  now  give  the  formal  definition  of  wiiat  we  call  the  Algebra 
of  Functions  Sequencing. 

Definition:  The  algebra  of  function  sequencing  O  =  <H,  *,  e,  0,  ?i> 
is  defined  as  follows: 

Primitives: 

H  -a  finite  set  of  functions,  such  that  H  =  {x  |  x  is  a  function}. 

*  -a  strictly  left-associative  sequence  binary  operator  which 

expresses  the  semantics  of  a  sequential  function  execution 

ordering. 

©  -a     commutative,     associative     binary     operator  wh  ich 

expresses  expresses  the  semantics  where   no   particular  order 

of  function  execution  is  required. 

0  -the    null    function;    a    function    which,     when    executed, 

performs  no  task. 

X    -the   exception   function;   a  function   which,   when   executed, 

signals  an  error  condition. 

Assume  that  H  is  a  finite  set  of  functions.     Then  the  notion  of 
an  inverse  function  is  defined  as  follows: 

Definition:  f-r  e  H  is  the  right  inverse  of  f  ifi  f  *  f-r  =  0  where 
0   is  the  null  function. 

The    above    says    that    if   the    execution    of   a    function,    f,    is 
immediately  followed  by  the  execution   of   its   right  inverse  function. 
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then  the  right  inverse  function  cancels  out  the  results  of  f.  This  in 
effect  is  the  same  as  if  f  were  never  executed.  A  right  inverse  may 
or  may  not  exist  for  any  function,  f.  For  example,  f  =  "Drill  a  hole" 
may  have  no  right  inverse  available  in  H. 

Axioms: 

1 .  fi  ®  f2  =  f2  ®  fi  ®  is  commutative 

2.  Square  bracket  placement  (not  order  of  expression  evaluation) 
fi  e  [f2  ®  fs]  =  [fi  ®  h]  e  fs  =  fi  e  f2  e  f3 

fl  *  [f2  *  fs]  =  [fi  *  f2]  *  fs  =  fi  *  f2  *  fa 

3.  identity  law:    3  0  in  H  such  that, 

0  e  f  =  f  0  identity  for  © 

0  *  f  =  f  *  0  =  f  0   identity  for  * 

4.  The  exception  function  X: 
3Xg  H  such  that 

X  ef  =  A., 

A.*f  =  >.and 

f  *  X  =  X  X  acts  as  a  zero  on  F  under  ®  and  *. 

5.  If    f  *  f-r  =  0    then, 

f-r  *  f  =  X  and  f-r  ©  f  =  >. 

Observation:  *  is  not  commutative,  therefore,  in  general 

f  1  *  f2  9^  f2  *  fi . 
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The  Algebra  of  Discrete  Assembly  Operations 

An  interesting  variation  of  the  above  algebra  is  what  we  call 
the  Algebra  of  Discrete  Assembly  Operations.  This  algebra  applies 
to  a  more  restricted  domain  and,  as  a  consequence,  exhibits  more 
structure.  The  more  structure  an  algebra  possesses,  the  richer  its 
stock  of  theorems  and  the  more  closely  it  can  model  the  application 
domain   [Berztiss,   1975]. 

An  assembly  operation,  A,  is  uniquely  identifiable  by  the  type, 
t,  of  operation  involved  and  the  set  of  participant  parts,  P.  A  can 
therefore  be  defined  as  a  two  tuple: 

A  =  <t,  P>,    where  t  &  T,    7  is  the  set  of  all  types  of  discrete 
join  operations,  and  P  is  the  set  of  participant  parts. 

For  discrete  assembly  operations  we  make  the  following 
important  observation:  A  appears  only  once  in  any  assembly 
sequence.  This  is  due  to  the  fact  that  at  the  time  a  set  of  parts  are 
assembled,  the  parts  no  longer  exist  as  individual  parts.  It  is 
therefore  impossible  that  they  participate  in  the  same  assembly 
operation  again.     This  fact  is  captured  with  the  laws  shown  below. 

Definition:  The  Algebra  of  Discrete  Assembly  Operations 
O'  =  <H,  *,  ®,  0,  X>  is  defined  as  follows: 

Primitives: 

H  -a  finite  set  of  functions,  such  that  H  =  {x  |  x  is  a  function}. 

*  -a    strictly    left-associative    sequence    binary    operator   which 
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expresses    the    semantics    of    sequential    function    execution 

ordering. 

®  -a     commutative,     associative,     binary     operator  wii  ich 

expresses  expresses  tine  semantics  where  no  particular  order 

of  function  execution  is  required. 

0  -the    null    function;    a    function    which,    when    executed, 

performs  no  task. 

X,    -the    exception    function;    a   function    that,    when    executed, 

signals  an  error  condition. 

Axioms: 

Axioms  1  through  5  from  algebra  O. 

6.  Idempotent  laws: 

f  0  f  =  f 
f  *  f  =  f 

7.  [fi  ®  f2]  *  [f2  e  fa]  =  [fi  ®  f2]  *  f3 
[fi  *  f2]  e  [f2  *  fa]  =  fi  *  f2  *  f3 

8.  [fi  *  f2]  e  [fi  *  fa]  =  fi  *  [f2  e  fa]   Left   distributive    law 

of  *  over  ® 

9.  [fi  ®  f2]  *  [fi  e  fa]  =  [fi  *  fa]  ®  [f2  *  fa]  =  [fi  ®  f2]  *  fa 
Theorem  1: 

[fi  ®  fa]  *  [f2  ©  fa]  =  [fi  *  f2]  ®  fa  Right   distributive    law 

of  ®  over  * 
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Proof:  Using  axiom  1  the  left  hand  side  can  be  rewritten  as: 
[fi  e  fa]  *  [f2  e  fa]  =  [fi  e  fa]  *  [fa  e  fa]  which  by  axiom  7  is 
equal  to:    [fi  e  fa]  *  [fa  e  fa]  =  [fi  *  fa]  e  fa 


Axiom  1. 


Axiom  2. 


f, 
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Figure  12a.    Semantic  schemas  for  some  of  the  axioms. 
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Axiom  7 
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Axiom  8. 
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Figure  12b.    Semantic  schemas  for  some  of  the  axioms. 
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Figure  12  graphically  illustrates  most  of  the  axioms  presented 
here.  Note  the  one-to-one  correspondence  of  algebraic  expressions 
and  the  functional  diagrams.  The  utility  of  the  Algebra  of  Discrete 
Assembly   Operations  is  illustrated  below  through  some  examples. 

Discrete  Assembly  Examples 

Example  1  :  In  this  example  we  develop  a  set  of  discrete 
assembly  sequences  capable  of  assembling  a  ball  point  pen.  We 
attempt  to  generate  the  "optimal"  sequences,  with  respect  to 
maximum  parallelism.  The  idea  is  to  break  the  assembly  sequence 
into  many  smaller  sequences  that  can  execute  concurrently.  This  is 
the  same  as  trying  to  place  as  many  A  associations  as  possible 
higher  towards  the  root  of  the  functional  semantic  schema  (i.e.,  try 
to  push  Fas  low  as  possible). 

As  a  first  step,  we  specify  the  assembly  operations  that  need 
to  be  performed.  Figure  13  shows  the  different  parts  involved  in  the 
assembly,  plus  the  assembly  operations. 

In  step  2  of  this  process  we  collect  all  the  assembly 
constraints  that  are  imposed  on  the  assembly  operations.  These 
constraints  are  usually  imposed  by  factors  such  as  the  space 
occupancy  laws  (you  cannot  join  something  to  a  part  that  is  hidden 
by  some  other  part)  or  simply,  user  imposed  constraints.  A  user 
constraint  may  be  specified  in  order  to  force  a  particular  sequence 
of  operations.  For  example,  we  may  want  to  avoid  the  difficult 
operation  of  attaching  the  ink-tube  to  the  head  if  we  have  already 
attached  the  head  to  the  body  (see  Figure   13).     For  this  particular 
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example  we  decide  on  the  following  assembly  constraints:  fa  *  fi 
and  f2  *  fa-  The  first  constraint,  in  accordance  to  a  space  occupancy 
laws,  simply  states  that  joining  the  head  to  the  body  will  be  an 
impossible  operation  if  we  already  joined  the  cap  with  the  body.  The 
second  constraint  is  a  user  constraint  which  says  that  we  should 
connect  the  ink-tube  to  the  head  before  we  join  the  head  to  the  body 
in  order  to  avoid  the  undesired  operation  mentioned  above. 


Cap 


Head 


Ink  Tube 


Body 


[=0 


Button 


Assembly  Operations: 
^1    :  Cap -Body 
fa   :Head  -  Ink  Tube 
^3  :  Head  -  Body 
f^  :  Body  -  Button 


Assembly  rules: 


^3    *    ^1 


f2   *    ^3 


Figure  13.  Discrete  assembly  of  a  ball  point  pen 


In   step  3   we   form   a   set,    C,   containing    all   constraints   from 
step    2    plus    all    remaining    assembly    operations    that    do    not 
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participate  in  any  of  the  constraints.     For  our  example  this  set  is  as 
follows:  C  =  {U,  fa  *  fi,  f2  *  fa}- 

Step  4  calls  for  forming  what  we  call  the  manufacturing 
process  characteristic  equation,  E.  This  equation  is  formed  by 
combining  all  elements  of  the  set,  C,  using  the  e  operator.  For  the 
equation,  C,  above  we  have:  E=  f4  ©  fs  *  fi  e  f2  *  fa. 

Step  5  calls  for  simplification  of  the  manufacturing  process 
ctiaracteristic  equation  (if  any  simplification  is  possible)  using  the 
axioms  and  theorems  of  the  Algebra  of  Discrete  Assembly 
Operations.  In  our  case  we  have  the  following  equation:  f4  e  [fs  * 
fi]  ©  [f2  *  fa]  which  by  axiom  1  we  could  rearrange  as  :  f4  ©  [f2  *  fa] 
©  [fa  *  fi].  Finally,  using  axiom  7a  we  get  the  final  expression 
which  is:  f4  ©  [f2*fa*fi]-  The  corresponding  functional  schema  is 
shown  in  Figure  14, 


^4  ©  [  f2  *  ^3  *    ^1  ] 


<=^ 


3  "1 


Figure  14.     Functional  schema  corresponding  to  assembly  of 

Figure  13. 
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Example  2:  Example  2  deals  with  the  assembly  of  a  flashlight. 
The  parts,  as  well  as  the  manufacturing  operations  involved,  are 
shown  in  Figure  15.     The  assembly  constraints  are  as  follows: 


1)  fi  *  f3 

3)   fs  *  f6 


2)  f2  *  f3 

4)  h  *  U 


Front 


Lens 


Reflector 


Back 


Barrel 


Assembly  Operations: 
:  Front  -  Lens 
:  Reflector  -  Lamp 
:  Reflector  -  Front 
:  Front  -  Barrel 
:  Spring  -  Back 
:  Back  -  Barrel 


Assembly 

rules: 

fi 

*     f3 

^2 

*    ^3 

^5 

*^6 

^3 

*    ^4 

Figure  15.  Discrete  assembly  of  a  flashlight. 
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The  manufacturing  process  characteristic  equation  is  as 
follows:  E  =  [fi  *  fa]  e  [f2  *  fs]  ®  [fs  *  fe]  ®  [fa  *  f4].  Combining 
terms  1  and  2  using  axiom  9,  we  get:  [[fi  ©  f2]  *  is]  ®  [fs  *  fe]  ®  [fa  * 
f4].  By  letting  fi  ®  f2  =  f,  this  equation  can  be  rewritten  as:  [f  *  fa] 
®  [^5  *  ^e]  ®  [^3  *  ^4]-  Now  if  we  apply  axiom  1  we  get:  [f  *  fa]  ®  [fa 
*  f4]  ®  [fs  *  fe]-  Again  combining  terms  1  and  2  using  axiom  7,  we 
get:  [f  *  fa  *  f4]  ®  [fs  *  fe].  As  a  final  step  we  substitute  t  for  [fi  e 
f2]  to  get  the  final  expression:  [[fi  ®  f2]  *  fa  *  f4]  ®  [fs  *  fe].  Figure 
16  shows  the  corresponding  functional  schema. 


[[fi®f2]**3*f4]®n5*  fe]         «=^ 


^3        U     fs  fe 


U  ^2 


Figure  16.     Functional  schema  corresponding  to  assembly  of 

Figure  15. 


A  Methodological   Procedure  for  Generating   Functional  Semantic 
Schemas  Correspondinc  to  Manufacturing  Procedures 

In  the  previous  section  we  presented  the  Algebra   of  Function 

Sequencing    and    illustrated    its    utility    by    means    of   few    simple 

examples.       In    this    section    we    present    a    more    methodological 

approach  to  the  generation  of  a  functional  semantic  schema  capable 
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of  describing  a  set  of  implementation  alternatives  for  a 
manufacturing  procedure.  A  detailed  procedure  is  presented  wiiich 
accepts  as  input  a  set  of  subfunction  sequencing  constraints  in  the 
form  of  a  partially  ordered  set  (POSET)  and  generates  a  functional 
semantic  schema.  This  semantic  schema  explicitly  represents  all 
valid  manufacturing  plans  that  satisfy  the  sequencing  constraints 
and  are  consistent  with  the  manufacturing  procedure  they  describe. 

First,  some  background  information  is  presented.  This 
information  deals  with  some  useful  properties  of  POSETS.  As 
previously  discussed  (see  Chapter  5),  function  sequencing 
constraints  can  be  described  by  a  POSET.  A  POSET  can  be 
represented  by  a  POSET  diagram  [Berzitiss,  1975].  The  procedure 
presented  here  derives  a  functional  semantic  schema  starting  with  a 
POSET  diagram. 

Note  that  the  definition  of  the  F  association  is  similar  to  the 
partial  order  relation  '<.'  The  difference  between  them  is  that  F  is 
not  reflexive.  For  functions  fj,  fj,  fj  <  fj  =>  fj  <  fj,  if  i  9t  j. 
Therefore,  an  expression  of  the  form  fj  <  fj  can  be  written  as  fj  *  fj, 
which  means  that  the  execution  of  the  function  fj  directly  precedes 
the  execution  of  fj. 

Given  a  POSET  diagram,  we  could  define  different  levels  on 
this  diagram  as  follows: 

•  All  maximal  nodes  on  the  POSET  diagram  are  assigned  to  level  0. 

•  All  nodes  directly  connected  to  nodes  of  level  0  are  assigned  as 
nodes  of  level  1.  In  particular  node  fj  is  assigned  to  level  1  if 
fj  <  fj,  i  5t  j  where  fj  is  a  node  of  level  0. 
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•  In  general,   node  fj  is  assigned  to  level  K  if  there  exists  fj  <  fj  and 
fj  is  already  assigned  to  level  K-1. 

•  All    single    disconnected     nodes    are    assigned    to     level    zero. 

Consider  the  diagram  shown  in  Figure  17  as  an  example.  This 
diagram  has  one  maximal  element  namely,  fg.  Therefore,  layer  zero 
consists  of  only  node  fg.  Layer  one  consists  of  nodes  fy  and  fs  since 
both   nodes  are  <  related  to  fg  (i.e.,  fy  <  fg  and  fs  <  fg).      Similarly, 


Figure  17.    Example  of  a  rather  complex  POSET  diagram 
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nodes  U,  fs.  and  fe  belong  to  layer  2,  nodes  f2  and  fs  belong  to  layer 
3  and,  finally,  node  fi   belongs  to  the  last  layer,  which  is  layer  4. 

Note  that  functions  at  the  lower  part  of  the  diagram  need  to  be 
executed  before  functions  higher  in  the  diagram.  For  example,  node 
fg  in  Figure  17  could  only  be  executed  after  the  execution  of  both 
functions  fy  and  fs  has  completed.  Similarly,  execution  of  function 
U  requires  that  execution  of  function  f2   is  completed. 

The  above  discussion  leads  to  the  following  observations: 

1.  The  execution  of  a  function  on  level  K  depends  only  on  the 
execution  of  functions  of  level   K-1. 

2.  All  functions  that  belong  to  the  same  level  exhibit  no 
dependencies  to  each  other.  Therefore  these  functions  can 
potentially  be  executed  concurrently  (i.e.,  they  are  A 
associated). 

3.  Given  a  function  fj  belonging  to  level  K,  and  fj  and  f|  of  level 
K-1  such  that  fj  e  fj  and  f|  0  fj,  we  could  write  the  following 
expression  [fj  *  fj]  0  [f|  *  fj]  which  by  axiom  9  reduces  to 
[fj  ©  f|]  *  fj.  This  last  expression  confirms  observation  2 
above,  in  that  it  states  that  fj  needs  to  execute  after  both  fj 
and  f|,  but  fj  and  f|  can  execute  concurrently,  since  they  both 
belong  to  the  same  level  . 

We  now  present  a  methodology  which  enables  us  to  generate  a 
functional    semantic   schema   describing    a    manufacturing   procedure 
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starting    with     the     set    of    sequencing     constraints     among     the 
subfunctions  of  that  procedure. 

Procedure: 

1.  Given  a  set  of  function  sequencing  constraints,  build  a  POSET 
diagrann.  See  [Berzitiss,  1975]  for  a  detailed  procedure  for 
accomplishing    this. 

2.  Assign  levels  on  the  POSET  diagram  using  the  method 
discused  above. 

3.  For  all  levels  K,  where  K  =  0  to  N  and  N  is  the  maximal  level. 
write  expressions  describing  the  <  relations  (or  equivalently 
the  F  associations)  among  nodes  of  levels  K  and  K-1.  The 
expressions  are  of  the  form  fj  *  fj  where  fj  belongs  to  level  K 
and  fj  belongs  to  level  K-1.  Use  the  axioms  presented  in 
Chapter  6  to  simplify  the  expressions  if  possible.  Note  that 
only  simplifications  that  factor  out  functions  belonging  to 
level  K-1   are  done. 

4.  If  more  than  one  expression  exists  for  level  zero,  combine 
these  expressions  with  an  A   association. 

5.  Starting  at  level  zero  and  working  towards  level  N,  replace 
function  fj  of  level  K-1  with  the  (fn  e  ...)  *  fj  expression  of 
level  K,  if  such  an  expression  exists.  Continue  until  the 
maximal  level    N    is    reached.      The    result    is    a    functional 
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semantic  diagram  describing  the  different  ways  the  original 
manufacturing  process  can  be  implemented. 

To  clarify  the  above  procedure  an  example  is  presented  below. 


to 


Level  0 


Level  4 


Figure  18.    Example  of  a  POSET  diagram  with  defined  layers 


Assume  that  the  POSET  diagram  of  Figure  17  represents  the 
ordering  constraints  among  the  subfunctions  of  a  discrete  assembly 
manufacturing  procedure.  The  assignment  of  the  levels  is  shown  in 
Figure  18.  According  to  this  figure,  no  expressions  can  be  written 
for  Level  0.     The  expressions  ij  *  fg  and  fs  *  fg  are  written  for  Level 
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1.  These  expressions  are  then  simplified  to  [fj@  fs]  *  fg.  For  Level 
2  the  expressions  are  as  follows:  f4  *  fy,  f5  *  fy,  fs  *  fs,  and  fe  *  fs- 
Keeping  in  mind  that  we  are  trying  to  get  simpler  expressions  which 
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Figure  19.     Building  the  functional  semantic  schema. 
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factor  out  functions  that  belong  to  Level  1,  we  simplify  as  follows: 
[f4  ®  fs]  *  f?  and  [fs  ®  fe]  *  fs-  For  Level  3  we  have:  f2  *  fs,  fa  *  fs, 
f2  *  U  and  fa  *  fs,  which  can  simplify  to:  [f2  *  fs]  *  fs,  f2  *  f4  and 
fa  *  fs.  Finally,  for  Level  4  the  expressions  are:  fi  *  f2  and  fi  *  fa, 
which  do  not  further  simplify.  As  a  final  step,  we  construct  the 
diagram  by  substituting  nodes  of  higher  levels  with  the  expressions 
of  those  nodes  derived  in  the  next  lower  level.  This  is  graphically 
illustrated   in   Figure   19. 

Notice  that  function  fi  can  be  factored  out,  since  both  subnets 
of  Level  4  require  that  fi  be  executed  first.  Figure  20  shows  the 
resulting    functional   semantic   schema   after   this   simplification. 


Figure  20.     Resulting  functional  semantic  schema. 
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Previously  we  made  the  claim  that  any  partial  ordering  can  be 
represented  using   a  combination  of  A  and  F  associations.      Proof  of 
this  claim  is  provided  below: 

Theorem :  Any  partial  ordering  can  be  represented  by  a 
semantic  diagram  using  a  combination  of  A  and  F  associations. 

Proof:  By  induction  on  n,  the  number  of  elements  in  the 
partially  ordered   set. 

1.  Basis:  The  only  ordering  on  a  set  {fi}  can  be  fi  <  fi  and  can 
be  represented  in  the  semantic  diagram  by  a  single  node. 

2.  Induction  step:  Assume  the  claim  is  true  for  a  partially 
ordered  set  of  n-1   elements. 

Let  H  be  an  n  element  partially  ordered  set.  Since  H  is  finite, 
it  has  at  least  a  minimal  element,  say  fm-  If  fm  is  omitted,  then  the 
set  {H-fm}  having  n-1  elements  is  still  an  ordered  set  and,  by  the 
induction  hypothesis,  has  a  semantic  diagram  representation. 
Therefore,   incorporate  fm  in  this  semantic  diagram  as  follows: 

a.  Determine  the  level  on  which  fm  should  be  inserted.  Notice  that 
since  fm  is  a  minimal  element,  it  could  be  an  isolated  node.  If 
it  is  an  isolated  node  (which  means  that  fm  could  be  executed 
concurrently  with  any  other  function),  place  fm  in  an  A 
association  with  all  maximal  nodes  currently  in  the  diagram.  If 
fm  is  not  an  isolated  node,  then  it  can  only  be  inserted  into 
either  the  last  Level  N  or  in  a  new  Level  N+1.  The  later  case 
means  that  a  new  level  is  created.  Recall  that  elements  of 
some  level,  say  I,  can  be  F  related  only  with  elements  of  Level 
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1-1.  If  we  assume  that  N  is  currently  the  maximal  level,  and 
fm  is  F  related  to  elements  of  this  level,  then  fm  should  be 
inserted  into  a  new  Level  N+1.  On  the  other  hand,  if  fm  is  F 
related  to  elements  of  Level  N-1 ,  then  fm  should  be  inserted 
into  Level  N  and  no  new  level  is  created. 

b.  If  fm  is  to  be  inserted  in  a  new  level  (i.e.,  N+1),  write 
expressions  describing  the  <  relations  (or  equivalently  the  F 
associations)  among  fm  and  nodes  of  Level  N.  These 
expressions  are  of  the  form  fm  *  fj  where  fj  belongs  to  Level  N. 
Then  merge  Levels  N  and  N+1  by  replacing  links  pointing  to 
function  fj  of  Level  N,  with  links  pointing  to  fm  *  fj  of  level 
N+1. 

c.  If  fm  is  to  be  inserted  in  Level  N  (the  currently  minimal  level), 
write  expressions  describing  the  <  relations  (or  equivalently 
the  F  associations)  among  fm  and  nodes  of  Level  N-1.  These 
expressions  are  of  the  form  fm  *  fj  where  fj  belongs  to  Level 
N-1.  Every  such  node,  fj,  of  Level  N-1  can  either  be  a  leaf  node 
on  the  semantic  diagram  or  it  can  correspond  to  a  subnet.  If  it 
is  a  leaf  node,  then  replace  links  pointing  to  function,  fj,  with 
links  pointing  to  the  expression  fm  *  fj  of  Level  N.  In  the  case 
that  fj  corresponds  to  a  subnet,  this  subnet  being  of  the  form 
[fn  ©  fp  ®  ...]  *  fj  needs  to  be  combined  with  the  expression 
fm  *  fj-  The  resulting  expression  is  [fn  ©  fp  ©  ...  ©  fm]  *  fj  and 
replaces  the  original  subnet.  The  result  is  a  semantic  diagram 
for  H. 


CHAPTER  7 
THE  CONTROL  MODEL 


This  chapter  starts  with  a  brief  introduction  to  Petri  net 
theory.  We  then  discuss  the  organization  of  the  control  knowledge 
base.  The  chapter  concludes  by  presenting  a  simple  methodology 
which  allows  the  transition  from  the  functional  semantic  net 
representation  (i.e.,  the  manufacturing  plan  captured  by  the 
functional  schema)  to  a  corresponding  Petri  net  representation.  The 
Petri  net  resulting  from  this  transformation,  as  will  be  discussed 
further,   constitutes  the  skeleton  for  the  workcell  control. 

Introduction  to   Petri   Net  Theory 

This  section  is  a  brief  introduction  to  Petri  net  theory.  Only 
the  basic  ideas  are  presented  here.  A  more  comprehensive  study  of 
Petri  nets  can  be  found  in  the  book  by  Peterson  [Peterson,  1981]. 

Petri  nets  consist  of  a  graphical  and  mathematical  tool  with 
great  potential  in  modeling  systems  which  are  characterized  as 
being  concurrent,  asynchronous,  parallel,  non-deterministic  and/or 
stochastic.  As  a  mathematical  tool,  it  allows  building  mathematical 
models  that  describe  the  system's  behavior  [Murata,  1989]. 
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What  are  Petri  Nets? 

A  Petri  net  is  a  directed,  weighted,  bipartite  graph  consisting 
of  two  kinds  of  nodes  called  places  and  transitions.  Directed  arcs 
connect  a  place  to  a  transition  or  a  transition  to  a  place. 
Graphically,  we  draw  places  as  circles  and  transitions  as  bars  (see 
Figure  21).  Arcs  can  be  labeled  with  a  weight,  which  is  a  positive 
integer,  such  that  a  k-weighted  arc  is  equivalent  to  drawing  k 
parallel  arcs.  The  label  for  an  arc  with  weight  of  one  is  usually 
omitted. 


Figure  21.  A  Petri  net. 
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A  marking,  M,  on  a  Petri  net  is  a  mapping,  M:  P  -»  I,  where  P  is 
the  set  of  places  and  I  is  the  set  non-negative  integers.  M  assigns 
tokens  to  each  place  in  the  net.  If  a  marking  assigns  to  place  p  a 
non-negative  integer,  k,  we  say  that  p  is  marked  with  k  tokens. 
Graphically,  we  place  k  dots  (representing  the  tokens)  in  the  circle 
representing  place  p.  Sometimes  it  is  convenient  to  view  M  as  an 
m-element  vector  (where  m  is  the  total  number  of  places)  whose  i^^ 
component,  denoted  as  M(i),  is  the  number  of  tokens  in  place  pj. 

A  formal  definition  of  a  Petri  net  is  as  follows  [Murata,  1989]: 

Definition: 

A  Petri  net  is  a  5-tuple,  Pn  =  <P,  T,  F,  W,  Mo>    where: 

P  =  {P1.P2,  ■■•,Pm}  is  a  finite  set  of  places, 

T  =  {ti,  t2,  ....  tn}  is  a  finite  set  of  transitions, 

F  c  (P  X  T)  u  (T  X  P)  is  a  set  of  arcs, 

W:  F  ^  {1,  2,  3,  ...}  is  a  weight  function, 

Mo:  P    {0,  1,  2,  3,  ...}  is  the  initial  marking  and 
PnT  =  0   and  PuT;t0. 

We  present  below  a  few  more  definitions  which  are  necessary 
for  understanding  the  material  in  the  rest  of  this  chapter. 

1.  The  set  of  input  places  for  a  transition,  t,  is  given  by 
l(t)  =  {p  I  (p,  t)  e  F}  and  the  set  of  output  places  of  a 
transition,  t,  is  given  by  0(t)  =  {p  |  (t,  p)  e  F}.  Figure  22 
illustrates    this   for   transition    ti . 
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l(t)  =  {p^P  k 
0(t)  =  {p^p] 

P2  is  a  source, 

p,  is  a  sink. 

4 


Figure  22.   Illustrating   Petri  net  concepts. 


2.  A  transition  without  an  input  place  is  called  a  source 
transition  and  is  always  enabled. 

3.  A  transition  without  any  output  place  is  called  a  sink 
transition.  The  firing  of  a  sink  transition  consumes  tokens 
but  does  not  produce  any. 

4.  A  transition,  t,  is  said  to  be  enabled  if  every  place,  p  e    l(t), 

is  marked  with  at  least  W(p,  t)  tokens,  where  W(p,  t)  is  the 
weight  of  the  arc  from  p  to  t.  In  other  words,  for  t  to  be 
enabled  every  input  place  p  of  t  has  to  have  at  least  as  many 
tokens  as  arcs  from  p  to  t  (see  Figure  23a). 

5.  Firing  an  enabled  transition,  t,  removes  W(p,  t)  tokens 
from  each  input  place,  p  e  l(t)  and  places  W{t,  p)  tokens  to 
each  output  place,  p  €  0(t),  (see  Figures  23a  and  23b). 
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6.  A  finite  capacity  Petri  net  is  a  Petri  net  in  which  each 
place,  p,  has  an  associated  capacity,  K(p),  which  is  defined  as 
the  maximum  number  of  tokens  that  p  can  hold  at  any  time.  A 
finite  capacity  Petri  net  is  used  when  modeling  systems  that 
contain   finite  buffers,   etc. 


a) 

Marking  before  firing, 
t^  is  an  enabled  transition 


b) 

Marking  after  firing. 

Transition  t  isjnot 
enabled  any  more 


Figure  23.   Illustrating  the  firing   mechanism. 
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Petri  nets  have  been  used  to  model  and  simulate  a  wioe  variety 
of  problems.  These  include  operating  systems  and  parallel  machines 
[Lautenbach  and  Schmid,  1974;  Baer  and  Ellis,  1977],  chemical 
reactions,  and  manufacturing  [Lipp,  1983;  Martinez  et  al.;  1986; 
Casein  et  al.,  1992]. 

According  to  the  application  domain,  the  Petri  net  entities 
(namely  the  transitions,  places  and  tokens)  are  given  a  meaning  or 
interpretation.  In  the  manufacturing  domain  we  usually  have  the 
following  interpretation:  Transitions  represent  manufacturing 
processes,  places  represent  buffers  or  decision  points  and  tokens 
represent  parts  or  information   units. 

Petri  nets  can  be  used  to  represent  the  manufacturing  WC 
control  in  a  top-down  fashion  at  various  levels  of  abstraction  and 
detail.  For  example,  a  single  transition  at  a  higher  level  such  as 
"place  part  into  buffer"  may  be  expanded  at  a  lower  level  into  a 
sequence  of  transitions.  This  sequence  may  be  "locate  part." 
"pick-up  part,"  "locate  buffer"  and  "place  part."  The  use  of  different 
levels  of  abstraction  allows  the  manufacturing  engineer  to  work  at  a 
particular  level,  without  having  to  worry  about  the  implementation 
of  all   lower  levels. 

PN  Examples 

Below,  several  examples  of  Petri  nets  are  presented.  These 
Peri  net  constructs,  as  discussed  later,  are  very  useful  in  developing 
control  models  for  structural  objects,  as  well  as  combining  a  set  of 
control  models  to  build  complex  and  comprehensive  workcell  control 
algorithms.     The  simple  Petri  nets  presented  here  enable  us  to  model 
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activities    such    as    process    sequencing,    process    synchronization, 
resource  sharing  through  mutual  exclusion,  and  part  buffering. 

Example  1 :  Figure  24a,  shows  a  sequence  Petri  net  diagram. 
This  Petri  net  diagram  captures  the  semantics  of  sequential 
execution.  Referring  to  the  figure,  notice  that  when  place  pi 
receives  a  token,  transition  ti  becomes  enabled.  When  transition  ti 
fires,  place  p2  receives  the  token.  This  in  turn  enables  transition  ts. 
In  general,  it  takes  i-1  firings  for  a  token  to  propagate  from  pi  to 
place  Pi  (in  which  case  transition  ti  becomes  enabled).  As  a  result 
of  this  activity  functions  corresponding  to  pi,  P2,  P3.  ■■•-  Pn  are 
executed  one  after  the  other  (i.e.,  sequentially)  in  the  specified 
order. 

Example  2:  Figure  24b  shows  a  selection  Petri  net  diagram. 
According  to  this  diagram  when  place  pi  receives  a  token 
transitions,  ti,  t2,...tn  become  enabled.  Since  tokens  are  not 
divisible,  only  a  single  transition  can  consume  the  token  and 
therefore  only  one  transition  can  fire.  The  decision  on  which 
transition  (either  ti  or  t2  or...  or  tn)  can  fire  depends  on  the  boolean 
conditions  ci  to  Cp.  A  condition,  Ci,  evaluates  to  true  only  if  ti  is  to 
fire.  Note  that  these  conditions  should  be  set  exclusive,  which 
means  that  under  no  circumstances  can  two  conditions  evaluate  to 
true  at  the  same  time.  Therefore,  the  arrival  of  a  token  to  place  pi 
causes  the  firing  of  at  most  one  transition.  As  a  result  of  this 
firing,  place  P2  receives  the  token.     This  Petri  net  construct  models 
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the    well    known    case    statement    provided    by    many    programming 
languages. 

Example  3:  Figure  24c  shows  a  synchronization  Petri  net 
diagram.  Using  this  Petri  net  construct  we  may  force  one  or  more 
activities  to  wait  for  the  completion  of  one  or  more  other  activities 
(i.e  .synchronize  them).  In  the  example  shown  in  Figure  24c  assume 
that  Pi  receives  a  token  (due  to  a  firing  of  some  transition,  tj),  while 
Pj  holds  no  token.  In  this  case  transition  tk  is  not  enabled.  In  fact, 
transition  tk  will  not  became  enabled  until  a  token  reaches  place  pj. 
When  both  pi  and  pj  receive  a  token  then  tk  becomes  enabled  and 
fires.     This,  in  effect,  restarts  both  pi  and  pj   together. 

Example  4:  Figure  24d  shows  a  mutual  exclusion  Petri  net 
diagram.  Let's  assume  that  two  robots  are  using  the  same  part 
feeder.  In  order  to  avoid  robot  collisions  we  require  that  only  one 
robot  can  use  the  part  feeder  at  a  time.  For  a  robot  to  gain  access  to 
the  part  feeder  there  must  be  a  token  in  pi  or  p2,  as  appropriate, 
signaling  its  intention  to  use  the  feeder  and  there  must  be  a  token  in 
Pk  indicating  availability  of  the  feeder.  As  long  as  one  robot  has 
access  to  the  feeder,  no  token  exists  in  place  pk,  indicating  that  the 
feeder  is  in  use,  therefore  disabling  any  other  attempts  to  access 
the  feeder.  If  both  robots  request  the  use  of  the  feeder 
simultaneously  (i.e.,  places  pi  and  P2  have  a  token),  then  the 
transitions  CSi  and  CSj  are  in  conflict  and  only  one  of  them  can  fire. 
The  firing  of  one  of  the  transitions  removes  the  token  from  pk  and 
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therefore  disables  the  other,   forcing    it  to  wait   until  the  first   robot 
gives  up  the  use  of  the  feeder  by  placing  a  token  back  in  pk 


tii=r=i 


t„^ 


a.  Sequence 


CSi 

=  Critical  Section 

Process  i 

CSj 

=  Critical  Section 

Process  j 

PR 

=  Producer 

CO 

=  Consumer 

b.  Selection 


1 


c.  Synchronization  d.  Mutual  exclusion 


i  -  J 

e.  Producer-consumer 


Figure  24.     Petri  net  representation  of  control  constructs 
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Example    5:    Figure   24e  shows   a   producer-consumer   Petri   net 
diagram  with  a  finite  size  buffer.     Let's  assume  that  two  robots  are 
using  a  single  buffer.     The  first  robot  places  parts  into  the  buffer,  if 
not   already   full,    while   the   second    robot   retrieves    parts   from    the 
buffer,    if    the    buffer    is    not   empty.       To    avoid    robot   collision    we 
require  that  only  one  robot  uses  the  buffer  at  a  time  (i.e.,  we  require 
mutual  exclusion).     The  buffer  is  bounded,  which  means  that  it  has  a 
maximum   capacity  of  N   parts.     To  avoid   buffer  overflow  (trying   to 
place  a  part  in   a  full  buffer)  or  underflow  (trying  to   remove  a  part 
from   an    empty   buffer),   the   bounded    buffer   is   represented   by  two 
places;  BF  which  represents  the  number  of  full  buffer  positions  and 
BE  which   represents  the  buffer  empty  positions.      Initially,   BE  has  N 
tokens,  indicating  that  all  buffer  positions  are  empty,  where  BF  has 
zero  tokens,   indicating  zero  parts  in  the  buffer.      If,   at  some  point, 
the    buffer    gets    full,    then    BE    will    have    zero    tokens    therefore 
disabling  the  producer.     Note  that  the  consumer  is  still  enabled  since 
BF  has  tokens.     In  the  case  that  the  buffer  is  empty,  then  BF  has  no 
tokens,  therefore  prohibiting  the  consumer  from   retrieving  any  parts 
from  the  empty  buffer. 

Control  Representation 
The  control  knowledge  base  can  be  conceptually  divided  into 
two  parts.  The  first  part  stores  general  knowledge  about  the  WC 
control  in  the  form  of  a  set  of  control  primitive  constructs.  The 
second  part  of  the  control  knowledge  base  stores  the  actual  control 
structures  that  implement  the  control  algorithms  for  the  various  WC 
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devices  and/or  workcells.      Figure  25  shows  the   semantic  diagram 
describing  the  control  knowledge. 


C^ 


Controls 


Control 
Primitive 


Parent-control 


Control 

Implementation 

Structure 


Figure  25.  Control  knowledge  schema. 


General  WC  Control  Knowledge 

As  an  initial  attempt  to  characterize  general  control 
knowledge  at  the  semantic  level,  we  propose  a  simple  taxonomy 
{Generalization)  of  control  constructs  commonly  encountered  in  the 
manufacturing  domain.  These  constructs  have  parameterized 
descriptions  in  terms  of  Petri  nets  that  can  be  instantiated  and 
combined    together    according    to    appropriate    rules    and    control 
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algorithms    in    order    to    build    different    control    strategies    for    the 
workcell   active  components. 

For  the  sake  of  simplicity  we  restrict  our  attention  to  a 
simplified,  multi-agent  context,  with  concurrent,  independent  or 
competitive  (sharing  common  resources)  agents.  This  means  that  we 
do  not  consider  certain  more  complex  cooperating  behaviors  such  as, 
for  example,  the  case  of  two  robots  cooperating  to  carry  the  same 
load  or  the  case  in  which  one  of  them  is  holding  a  part  while  the 
other  is  performing  machining  operations  on  it.  Also,  we  assume 
that  each  agent  can  handle  sequential  activities  only.  As  a 
consequence  of  these  hypotheses,  the  control  knowledge  schema  can 
be  restricted  to  include  only  the  control  primitives  shown  in  Figure 
24.  This  minimum  set  of  primitives  allow  sequential  or  alternative 
activities  performed  by  each  agent,  synchronization,  mutual 
exclusion  and  producer-consumer  relationships  among  agents.  Other 
constructs,  however,  can  be  defined  within  the  knowledge  base  and 
the  design  procedure  can  be  easily  extended  to  handle  them.  Caselli 
[Caselli  and  Faldella,   1988]. 

Control    Structures 

The  Semantic  diagram  of  the  control  knowledge  base  is  shown 
in  Figure  25.  We  define  an  object  class  called  "Control."  This  object 
class  models  the  general  notion  of  control,  and  is  partitioned  into 
two  subclasses,  namely  "Control  Primitive"  and  "Control 
Implementation  Structure."  The  class  "Control  Primitive"  stores  the 
general  WC  control  knowledge  primitives  as  discussed  above  and 
shown   in    Figure  24.      The   class   "Control   Implementation    Structure" 
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stores  the  Petri  net  constructs  that  implement  the  WC  control.  Note 
the  recursive  definition  of  the  control  class.  This  is  done  through 
the  attributes  Sub-control.  Parent-control  and  Interface-points.  As 
previously  discussed,  a  single  transition  at  a  higher  level  of 
abstraction  may  be  expanded  at  a  lower  level  into  a  Petri  net 
containing  a  set  of  other  transitions.  This  expansion  is 
accomplished  by  recursively  examining  the  Subcontrol  attributes  of 
the  transition,  to  find  all  its  subnets  (subcontrols),  then  examining 
the  Interface-points  attribute  to  find  out  how  to  combine  these 
sub-nets  in  order  to  reconstruct  the  original  transition.  The 
recursive  definition  allows  the  modular  construction  of  the  overall 
WC  control.  WC  component  control  implementation  structures  can  be 
represented  as  instances  of  this  class. 

The  Controls/Controled_by  links  map  the  instances  of  this 
class  to  the  actual  WC  equipment  (leaf  nodes  in  the  structural 
hierarchy)  for  which  they  implement  the  control. 
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CHAPTER  8 
TOP-DOWN  WORKCELL  DESIGN 


The  behavioral  or  functional  specification  is  the  highest-level 
specification,  which  indicates  what  must  be  done  and  not  how.  In 
the  workcell  design  activity,  the  goal  what  is  basically  dictated  by 
the  product  or  set  of  products  to  be  manufactured  by  the  workcell 
and  their  associated  processing  requirements.  Domain-specific 
knowledge,  either  available  in  catalogs,  databases  or  other  "sources 
of  expertise",  helps  the  designer  to  select  how  to  fulfill  these 
requirements  in  terms  of  customized  process  plans,  equipment, 
layout,  control  and  programming.  Due  to  the  large  number  of 
potential  solutions  and  different  design  styles,  we  do  not  expect, 
nor  recommend,  that  workcell  design  tools  be  capable  of  generating 
a  complete  design  without  human  intervention.  Rather,  since  the 
knowledge  stored  in  the  database  must  be  very  general  and  diverse, 
the  design  tools  will  typically  assist  a  human  designer  in  proposing 
and  evaluating  alternatives  at  different  design  stages,  thus  serving 
as  an  "Intelligent  Assistant"  [Papaconstantinou  et  al.,   1989b]. 

We  propose  to  semi-automate  the  above  process  by  providing 
the  designer  with  a  model  of  the  design  process,  as  well  as  tools 
that  will  aid  him  throughout  the  process.  We  envision  an  intelligent 
system  with  knowledge  about  manufacturing  procedures,  workcell 
equipment,  equipment  layout,  etc.     This  knowledge  could  be  collected 
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from  experts  in  the  field  and  captured  in  a  knowledge  base.    The  user 
can  then   consult  the   knowledge   base  to   derive   the   manufacturing 
plan,    select   and    lay    the    workcell    equipment    and    construct   the 
workcell    control. 

A    typical    interaction    of    the    designer    with    our    system    will 
consist  of  the  following   steps: 

1.  The  designer  provides  the  system  with  a  high  level  statement 

about  the  functionality  of  the  product  to  be  manufactured. 

2.  The  system  (here  we  assume  that  the  system  has  some 
knowledge  about  the  particular  product)  will  suggest  a 
sequence  of  manufacturing  processes  that  will  produce  the 
desired  product. 

3.  The  designer  will  accept,  refuse  or  modify  the  suggestions  of 

the   system.      This   dialogue   between    the    system    and   the 
designer  will  result  in  a  manufacturing  plan. 

4.  The  system,  using  this  manufacturing  plan,  will  be  able  to 
suggest  workcell  equipment  that  is  capable  of  providing  the 
functionality  implied  by  the  different  steps  of  the  plan.  The 
designer  at  this  point  could  choose  the  workcell  equipment 
from  the  proposed  alternatives.  A  three  dimensional 
computer  graphics  workcell  layout  system  will  allow  the 
designer  to  position  the  selected  workcell  equipment  into  the 
workcell   space. 
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5.  After,  as  well  as  during,   the   layout  process  the  system  will 

perform  a  validity  test  on  the  workcell.  This  will  include 
tests  on  reachability  (whether  every  auxiliary  device  is  in 
the  reach  of  at  least  one  transport  device),  any  violation  of 
space  occupancy  constraints  (no  two  pieces  of  equipment  can 
be  placed  such  that  their  volume  is  overlapping),  etc. 

6.  Using  the  manufacturing  plan,  workcell  layout  and  information 
about  the  workcell  equipment  as  well  as  some  input  from  the 
user,  the  system  will  attempt  to  produce  a  'Petri  net' 
representation  for  the  workcell  control  structure.  Tools  will 
allow  the  user  to  run  simulations,  predict  cycle  times  and 
experiment   with    different   alternatives. 

Design  Procedure 
The  workcell  design  procedure  that  we  propose,  in  agreement 
with  other  studies  [Suri  and  Whitney,  1984;  Alami  and  Chochon 
1985;  Fisher,  1985],  is  illustrated  in  Figure  26.  This  manufacturing 
workcell  design  methodology  makes  use  of  the  developed  theory, 
tools  and  ideas  presented  in  the  previous  chapters.  The  methodology 
is  intended  to  be  used  as  the  skeleton  of  a  software  tool  that 
assists  in  the  manufacturing  workcell  design  process.  The  proposed 
design  procedure  outlines  the  user's  view  (namely,  the 
manufacturing  engineer)  of  the  design  process.  The  design 
methodology  (and  the  workcell  design  software  implementation  of 
this  methodology)  is  knowledge  based.  This  implies  that,  for  the 
user  to   be  able  to  design   using   the  proposed   methodology,   some 
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preconditions    stiould    be    satisfied.       These    preconditions    are    as 
follows: 

1.  The  underlying  knowledge  base  contains  information  about  the 

manufacturing  processes  to  be  implemented. 

2.  The  underlying  knowledge  base  contains  structural  information 

about  a  substantial  number  of  different  workcell  components. 
This  will  enable  the  user  to  reach  an  acceptable  design  by 
experimenting   with   different   variations   of  the   workcell. 


1.  Define  product  -->    product  viewpoint 

2.  Select  process 

3.  Select  WC  equipment  -->  WC  equipment  viewpoint 

-  process  equipment 

-  part  routes 

4.  Allocate    functions/Define    transportation    architecture 

-  transportation    equipment 

-  fixtures/grippers 

-  buffers 

-  support  items 

5.  Layout  workcell 

6.  Describe  WC  control 


Figure  26.  The  steps  in  the  workcell  design  methodology 
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In  the  next  section  the  steps  involved  in  the  design  procedure 
are  illustrated  with  a  realistic  example.  The  example  illustrates 
the  design  of  a  workcell  which  accomplishes  the  simplified  task  of 
populating  printed  circuit  boards  (PCBs)  with  the  following  type  of 
components:  integrated  circuits  (ICs),  axial  components  (such  as 
resistors  and  diodes  packages)  and  radial  components  (such  as 
capacitors  packages). 

Illustrative    Fxample 

This  section  illustrates  the  proposed  workcell  design  shown  in 
Figure  26  through  an  extensive  example.  The  example  workcell 
described  here  is  based  on  a  real  WC  (see  Figure  27)  designed  and 
build  by  Western  Technologies,  a  medium  size  Florida  based  firm. 

For  the  sake  of  this  example  assume  that  a  manufacturing 
workcell  producer  firm  is  awarded  a  contract  to  design  and  build  a 
manufacturing  workcell  for  a  personal  computer  manufacturer.  The 
manufacturing  workcell  should  be  capable  of  populating  printed 
circuit  boards  (PCB's)  with  integrated  circuits,  resistors,  diodes, 
capacitors,  etc.  Parts  of  the  contract  specific  to  the  design 
requirements  are  reproduced  below: 

1.  "A  CAD  document  of  the  PCB  to  be  populated  is  produced  and  is 

made  available  by  the  PCB  designer  in  electronic  form." 

2.  "A  list  of  the  electronic  components  to  be  placed  on  the  PCB 

and    their    corresponding    insertion    coordinates    are    also 
provided   in  electronic  form." 
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3.  "The  ordering  of  the  list  of  electronic  components  specifies 
the  order  in  which  the  insertion  will  take  place."  (The 
difficult  problem  of  deriving  this  ordered  list  of  electronic 
components  is  the  well  known  problem  of  task  planning.  Much 
research  has  been  done  in  this  area  [De  Mello  and  Sanderson, 
1986;  De  Fazio  and  Whitney,  1987;  Fox  and  Kemph,  1987; 
Ayoub  et  al.,  1988],  but  still  no  satisfactory  solution  is 
found.) 
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Figure  27.    The  example  Workcell 
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4.  "After  insertion  of  a  part  on  the  PCB,  at  least  one  of  its  leads 

should  be  bend.  This  is  done  in  order  to  eliminate  the 
possibility  of  the  component  being  separated  from  the  PCB 
during   subsequent  transportation." 

5.  "Following  PCB  population,  the  board  will  undergo  wave 
soldering." 

6.  "The  cycle  time,  which  is  defined  as  the  time  needed  for  a 
component  to  be  processed  and  inserted  on  the  PCB,  must  be 
less  than  five  seconds." 

In  addition  to  the  contract  requirements  presented  above, 
other  constraints  may  be  imposed  on  the  design.  For  example,  this 
workcell  manufacturer  firm  had  difficulties  in  the  past  with  PCB 
wave  soldering.  After  considerable  investigation  it  was  discovered 
that  the  presence  of  dirt  on  some  of  the  component  leads  resulted  in 
inconsistent  solder  application.  To  eliminate  similar  problems  in 
the  future  the  firm  decided  to  establish  the  inclusion  of  cleaning  and 
tinning  operation  steps  as  standard  practice.  In  addition,  this 
particular  workcell  producer  firm,  due  to  economic,  expertise, 
reliability  and  other  reasons,  prefers  using  robots  from  a  particular 
manufacturer. 

The  above  discussion  shows  that  the  manufacturing  engineer 
responsible  for  the  workcell  design  generally  is  working  under  a  set 
of  constraints.      Keeping    in    mind   the   above  discussion,    lets  follow 
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the    manufacturing    engineer    through    the    different    steps    of    this 
hypothetical,   but  realistic  design   session. 

Product    Definitinn 

The  design  of  a  manufacturing  workcell  always  starts  with  the 
specification  of  the  product  or  family  of  products  to  be 
manufactured.  When  flexibility  is  pursued  and  a  large  family  of 
parts  is  targeted,  even  this  first  step  is  not  an  easy  one  and  might 
call  for  redefinition  later  [Whitney,  1986].  As  previously  discussed 
for  our  example  the  product  considered  is  a  Populated  PCB. 

Process    Selection 

Based  on  the  product  definition,  the  functional  knowledge  can 
be  searched  to  find  a  suitable  manufacturing  processes.  A  possible 
method  for  accomplishing  this  search  is  described  in  the  paper  by 
Cornelio  [Cornelio  and  Navathe,  1990].  From  our  viewpoint,  a 
process  is  a  partially  ordered  sequence  of  functions.  For  the  sake  of 
our  example,  assume  that  the  search  has  resulted  in  the  functional 
semantic  schema  shown  in  Figure  10.  Furthermore,  assume  that  the 
relevant  structural  knowledge  (a  small  part  of  the  structural 
hierarchy)  is  captured  in  the  schema  of  Figure  5. 

The  semantic  schema  of  Figure  10  actually  embodies  a  set  of 
alternative  manufacturing  plans.  Notice  at  the  lowest  level  of  the 
functional  schema  that  some  links  are  marked  with  the  symbol  'O.' 
These  links  capture  the  semantic:  "The  operation  pointed  to  by  this 
link  is  optional  and  can  be  either  included  or  omitted  from  the  final 
plan."      The   system   presents   the   engineer  with   a   partial   ordering 
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(captured  by  the  combination  of  A's  and  F's)  of  optional  and  non- 
optional  operations.  The  manufacturing  engineer  then  decides  which 
of  the  suggested  optional  operations  to  include  in  the  manufacturing 
plan.  The  elimination  of  operations  is  influenced  by  target  price, 
desired  performance  of  the  final  design,  standard  practices  and 
other  such  parameters. 

As  a  result  of  the  engineer's  decisions,  the  system  will  modify 
the  functional  semantic  schema  as  follows:  Eliminate  the 
corresponding  'O'  marked  link  whenever  an  optional  operation  is 
omitted,  otherwise  replace  it  with  an  unmarked  link.  These 
modifications  are  transparent  to  the  engineer  and  are  automatically 
handled  by  the  system.  The  manufacturing  engineer  need  only  be 
concerned  with  the  selection  of  the  optional  operations.  We  call 
this  activity  process  customization.  An  example  of  a  customized 
process  plan  is  shown  in  Figure  28.  According  to  this  figure,  the 
manufacturing  engineer  has  decided  that  radial  and  axial  components 
must  be  subjected  to  the  full  sequence  of  preprocessing  operations, 
but  no  test  is  performed  on  them.  The  ICs,  however,  undergo  both 
orientation  (OT)  and  electrical  (ET)  tests.  The  functional  knowledge 
in  Figure  28  at  this  point  makes  use  of  the  Generalization 
association  only  to  distinguish  among  the  different  types  of 
component  processing.  The  manufacturing  processes  are  fully 
specified,  although  their  exact  sequencing  is  not  known  yet.  The 
combination  of  A's  and  F's  specifies  a  partial  ordering  among  the 
operations.  Therefore,  Figure  28  still  represents  a  set  of 
alternative  manufacturing  plans.  Notice  that  neither  the  general 
manufacturing   process   in    Figure    10    nor   its   customized   version    in 
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Figure   28   contain    any   structural    information,    thus    representing    a 
true    task-level    specification. 


SL:  Straighten  Leads 
SCL:  Shape/Cut  Leads 
CL:  Clean  Leads 
TL:  Tin  Leads 

ETO:  Electrical  Test  Others 
ET:  Electrical  Test  IC 
OT:  Orientation  Test  IC 
INS:  Component  Insertion 
BLB:  Bend  Leads  Below 


Figure  28.  The  customized  process  plan 
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Equipment   Selection 

Equipment  selection  is  considered  to  be  a  critical  aspect  of 
the  manufacturing  workcell  design  due  to  its  direct  relationship  to 
capital  cost  [Heragu  and  Kusiak,  1987].  It  is  important  that  the 
designer  has  access  to  information  about  a  large  set  of  workcell 
equipment  (ideally  ail  existing  equipment).  This  will  enable  the 
designer  to  make  the  "best"  selection  that  satisfies  some  criteria 
(usually   efficiency   and/or  cost). 

In  the  workcell  equipment  selection  step,  structural  objects 
are  instantiated  from  the  Components  Library  (Figure  5)  into  the 
workcell  model.  First,  the  designer  is  required  to  select  equipment 
providing  the  subfunctions  included  in  the  customized  process  plan. 
This  step  is  called  process  equipment  selection.  Equipment  are 
retrieved  from  the  components  library  and  proposed  to  the  designer 
using  the  Provldes/Provided_by  relationships  originating  from  the 
objects  in  the  schema  in  Figure  28.  All  the  subfunctions  at  the 
leaves  of  the  schema  must  be  covered.  Some  equipment  might  cover 
more  than  one  subfunction  or  several  identical  devices  could  be 
instantiated  to  provide  the  same  function  with  an  increased 
capacity.  If,  for  some  subfunction,  no  suitable  piece  of  equipment  is 
present  inside  the  Components  Library,  the  designer  instantiates  the 
required  device  as  a  "virtual"  process  component.  Designs  with 
virtual  components  are  tagged  as  "incomplete."  Virtual  equipment 
may  be  required,  for  example,  when  some  special  fixture  must  be 
designed  in-house.  As  soon  as  a  suitable  component  model  has  been 
specified,    the   virtual   component   can    be    replaced   with    the   actual 


1  12 


model.      This   substitution    eliminates    uncertainties    and   drives   the 
design  closer  to  completion. 


SL:  Straighten  Leads 
SCL:  Shape/Cut  Leads 
CL:  Clean  Leads 
TL:  Tin  Leads 
ETC:  Electricai  Test  Others 
ET:  Electrical  Test  IC 
OT:  Orientation  Test  IC 
INS:  Component  Insertion 
BLB:  Bend  Leads  Below 


Figure  29.     The  process  plan  after  part  routes  definition 
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At  this  point,  in  addition  to  a  partial  ordering  (captured  in  the 
functional  semantic  network)  of  the  manufacturing  functions,  the 
manufacturing  engineer  will  have  established  a  set  of  workcell 
components  capable  of  providing  these  functions.  The  engineer  may 
further  constrain  this  partial  ordering  by  selecting  abstract  routes 
for  the  work-pieces.  These  are  paths  that  the  parts  follow  inside 
the  workcell  while  undergoing  processing.  The  specification  of 
these  routes  imposes  further  constraints  on  the  sequencing  of  the 
workcell  operations.  These  new  constraints  make  possible  the 
removal  of  some  A  associations  among  the  leaf  nodes  of  the 
functional  schema.  Up  to  this  point,  in  general,  the  functional 
schema  is  a  semantic  network.  By  specifying  the  sequencing  of 
operations  (when  selecting  abstract  routes  for  the  work-pieces),  in 
effect,  the  semantic  schema  is  reduced  to  a  functional  hierarchy. 
This  is  due  to  the  fact  that  if  a  functional  node  fj  is  pointed  to  by 
two  or  more  other  functional  nodes  fk,...,fm  (requiring  that  fj  be 
completed  before  fk,...,fm  can  be  completed)  and  the  execution  of  fj  is 
specified  in  order  to  satisfy  one  of  the  completion  requirements,  all 
other  completion  requirements  are  also  satisfied.  This  allows  the 
corresponding  links  to  be  removed  from  the  semantic  diagram, 
eliminating  the  inter-dependencies  due  to  functional   node  fj. 

The  process  plan  in  Figure  28  still  contains  a  number  of 
alternatives  (expressed  as  A  associations)  about  the  ordering  of 
subfunctions.  These  alternatives  may  be  removed  at  this  time.  Any 
A  association  remaining  in  the  schema  after  this  activity  suggests 
the  use  of  concurrent  operations.     Specifying  abstract  routes  for  the 
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parts  is  called  part  route  definition.     Figure  29  shows  the  functional 
hierarchy   after  the  routes  definition   step. 

Function     Allocation/Transportation     Architecture 

Once  the  equipment  has  been  selected,  the  operations  specified 
in  the  process  plan  can  be  assigned  to  the  "active  agents"  in  the 
workcell.  Many  different  situations  can  be  envisioned  in  this 
context.  In  the  simplest  scenario,  a  single  agent  exists  which  is 
entrusted  with  the  whole  process  plan  and  has  exclusive  usage  of  all 
the  resources.  A  radically  different  situation  is  represented  by 
many  agents  carrying  out  the  same  set  of  subfunctlons  and  using  the 
same  resources  in  a  fully  competitive  way.  Finally,  an  intermediate 
case  is  given  by  several  active  agents  interacting  in  a  cooperative 
way  by  means  of  well-defined  transactions.  These  transactions 
usually  entail  producer-consumer  relationships  using  buffer  areas 
and  mutual  exclusion  for  a  few  shared  resources  (regions  of  the 
physical  workspace  where  collisions  are  possible).  The  last 
situation  is  the  most  common  one.  Workcell  architectures  are 
usually  designed  to  establish  a  well-defined  flow  of  parts  among  the 
agents  in  order  to  reduce  the  time  wasted  in  non-process  operations. 
Partitioning  the  operations  among  the  active  agents  must  be 
consistent  with  the  number  and  type  of  transactions  specified 
among  them. 

Following  the  functional  allocation  step,  the  process  plan  is 
further  refined  by  the  addition  of  the  necessary  transport 
operations.  The  system  automatically  inserts  transportation 
operations   between   the  different   operations  when    necessary.      This 
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step  is  accomplished  by  utilizing  the  provides/provided_by  links.  If 
A  and  B  are  two  sequential  operations  in  the  process  plan  and  their 
corresponding  provides/provided__by  links  point  to  two  distinct 
workcell  components,  then  a  transport  operator  is  inserted  between 
them.  If  the  provides/provided_by  links  (P)  for  both  A  and  B,  point 
to  the  same  device,  there  is  no  spatial  separation  requiring  a 
transport  operation.  Due  to  the  fact  that  transport  operations  are 
automatically  derived  from  existing  knowledge  about  the  required 
functionality  and  capabilities  of  structural  components,  we  call 
transportation   operations   derived  operations. 

A  mathematical  formalization  of  a  derived  operation  is  given 
below: 

Given  a  partially  ordered  set  H  =  (F,  <)  where  F  is  a  finite  set 
of  functions,  i.e.,  F={fi,f2,  ...fn},  then  for  every  fj.fj  g  F,  such  that 
fi  <  fj,  a  cover  (i.e.,  the  execution  of  fj  directly  precedes  the 
execution  of  fj)  and  n(fi);tn(fj)  (i.e.,  the  provided_by  links 
corresponding  to  the  two  functions  point  to  different  workcell 
components)  insert  a  derived  transport  operation  T\\  in  F,  such  that: 
fj  <  Tij    and    Ty  <  fj. 

At  this  time  the  designer  can  introduce  explicit  parallelism  by 
using  the  concept  of  pipelining.  Recall  that  the  Functional 
Aggregation  association  enforces  sequencing  among  its 
subfunctions.  Pipelining  provides  a  viable  method  for  partitioning 
this  strict  sequencing.  Pipelining  is  accomplished  by  introducing  a 
buffering  operation  between  any  two  consecutive  subfunctions  of  a 
functional    aggregation  association.      The   introduction  of  the  buffer 
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has  the  effect  of  dividing  the  workcell  into  subareas  which  can  run 
independently,  requiring  synchronization  only  at  the  buffer  area. 

Given  a  functional  aggregation  F=[f-\,  iz,  --.fn].  U  ^  f2  ^•••-  ^  fn 
where  fj  is  a  subfunction,  then  by  introducing  a  buffering  operation, 
B  =  {Bi,  Bo},  where  Bj  =  place  in  buffer  and  Bq  =  pick  from  buffer, 
between  operations  fj,  fj  g  F,  we  can  replace  F  with  an  Aggregation 
association  of  two  aggregates  a^,  a2  such  that  (see  Figure  30): 

ai  =  (fi,f2.  ..,fi,Bi),   fi<f2<...,<fi,<  Bi 
and 

0C2  =  (Bo,  fi  +  1,  fi+2.    ...fj).     Bo  <  fi+1   <  fi+2  <...,  <  fj 
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Recall  that  the  Aggregation  association  permits  its 
subfunctions  to  be  executed  in  parallel.  Therefore,  inserting  a 
buffering  operation  into  a  list  of  sequential  operations  (an  F 
association)  is  equivalent  to  breaking  this  sequential  list  into  two 
sequential  sublists  which  can  now  be  executed  independently  and 
possibly  concurrently,  as  long  as  the  buffer  B  is  not  empty. 

During  the  next  step,  the  transport  operations  are  further 
refined  using  operations,  such  as  pickup,  move,  place,  put  in  buffer 
and  get  from  buffer.  Some  of  the  information  necessary  for  this 
refinement  should  be  available  from  the  structural  model  of  the 
selected  transport  device  itself.  Consider,  for  example,  the 
transport  operation  between  the  Straighten  Leads  (SL)  and 
Stiape/Cut  Leads  (SCL)  functions  of  Figure  29.  Assume  the  chosen 
transport  device  is  a  robot.  The  transport  operation  can  be 
decomposed  to  the  operations  (p/c/c,  move,  place)  as  shown  in  Figure 
31.  During  this  step  the  designer  plays  an  active  role  and  must  make 
some  decisions  about  the  basic  transportation  architecture.  Issues 
relevant  in  choosing  a  particular  transportation  architecture  are  the 
flow  of  parts  and  the  sequence  of  operations  (already  defined  in  a 
previous  step),  as  well  as  the  favored  transportation  equipment 
technology  and  price/performance  tradeoffs.  Again,  transportation 
equipment  is  included  in  the  workcell  model  by  instantiation  of  the 
corresponding  objects  from  the  Components  Library  in  Figure  5.  At 
this  stage  of  the  design  procedure,  part-interacting  devices  such  as 
grippers  and  fixtures  compatible  with  the  selected  transportation 
equipment  must  also  be  selected,  and  buffering  areas  instantiated. 
Finally,   static  support   items   such   as  tables  can   be   instantiated   in 
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the  workcell  modei,  although  such  items  are  more  typically 
introduced  as  refinements  after  several  iterations  of  the  layout 
step. 


Process 
component 


Test 


Figure  31.     Examples  of  expanding  the  transportation  operation 
and  introducing  pipelining  using  a  buffer. 


Developing  our  example  further,  we  suppose  that  the  designer 
has  decided  to  investigate  a  robot-based  architecture,  with  the 
workload   split  between  two   robots   (see   Figure  27).     The  first  one 
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entrusted  with  the  transportation  of  the  electrical  components 
between  the  preparation  operations.  The  second  robot  carries  out  IC 
testing  and  physical  insertion.  A  buffer  area  is  defined  by 
introducing  a  buffering  operation  between  the  Prepare  and  Test 
subfunctions  of  the  functionally  aggregated  class  Process 
component  (see  Figure  31).  Components  are  laid  down  in  the  buffer 
by  the  first  robot  and  retrieved  by  the  second  one. 

Workcell    Layout 

Workcell  layout  design  involves  several  iterations  through 
equipment  selection  and  placement.  It  typically  requires  returning 
to  previous  steps  in  the  workcell  design  methodology  (Figure  26). 
The  following  paragraphs  indicate  the  interaction  of  workcell  layout 
with  the  previous  design  steps. 

The  functional  specification  in  Step  2  leads  to  the  selection  of 
workcell  components  in  Step  3.  The  functional  schema,  in 
conjunction  with  the  selected  workcell  components,  dictates  a 
parts-flow  topology,  but  not  a  parts-flow  geometry.  The  parts-flow 
topology  indicates  the  sequence  of  workcell  component  visitations 
required  of  the  part  by  the  manufacturing  process.  Finding  an 
optimal  layout  of  the  workcell  components  consistent  with  the 
parts-flow  topology  is  a  standard  problem  in  manufacturing.  This 
mapping  of  the  parts-flow  topology  into  a  real  layout  is  a  research 
topic  [Black,   1988]  outside  the  scope  of  this  dissertation. 

The  structural  objects  instantiated  from  the  Components 
Library  in  Step  3  are  placed  in  a  model  of  the  physical  workspace 
whose  geometry   is   often   dictated   by   external   circumstances.      By 
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exploiting   the   workcell   component  geometrical   descriptions,   checks 
can   be  made  on   space  occupancy,   moving   object  interference  ana 
location   reachability   by  the  transportation  devices. 

Workcell  layout  also  strongly  affects,  and  is  affected  by,  the 
selection  of  transportation  devices,  buffers,  fixtures,  tooling,  etc. 
addressed  in  Step  4.  The  designer  will  typically  iterate  a  number  of 
times  between  Steps  3,  4  and  5  in  order  to  establish  a  layout  and  a 
transportation    architecture   consistent  with    design    requirements. 

The  layout  task  requires  the  designer  to  interact  with  a 
graphics  workstation  where  color  and  3D  features  play  a  crucial 
role.  Some  of  the  software  packages  commercially  available  already 
address  the  layout  step.  Preliminary  work  at  the  Machine 
Intelligence  Laboratory  has  led  to  a  prototype  layout  module  running 
on  a  Silicon  Graphics  workstation.  In  this  prototype,  structural 
objects  are  instantiated  from  a  Components  Library  developed  using 
Vbase,  a  commercial  object-oriented  database  system,  and  then 
located  in  the  workspace,  with  2D  and  3D  views  available  [Fernicola, 
1990]. 

Control    Synthesis 

During  the  high  level  design  stages,  the  functional 
specification  (functional  schema)  is  defined.  Furthermore,  workcell 
devices  are  selected  from  the  components  library  (structural 
schema)  and  instantiated.  At  the  lower  level  design  stages  the 
issues  dealing  with  workcell  control  need  to  be  resolved.  The 
functional  schema  itself  contains  a  substantial  amount  of 
information   that   is   useful   when   composing   the   workcell   control.      A 
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detailed  manufacturing  plan  is  available  directly  from  the  functional 
schema.  This  manufacturing  plan  constitutes  the  skeleton  of  the 
workcell  control  structure.  The  functional  schema,  as  previously 
discussed,  is  not  capable  of  explicitly  representing  concurrency,  nor 
supporting  simulation.  Recall  that  the  A  association  does  not 
dictate  concurrency,  but  only  denotes  the  permissibility  of 
concurrency.  To  address  these  deficiencies  of  the  semantic  schema 
representation,  our  model  uses  Petri  nets  to  describe  the  system 
control    structure. 

At  this  point,  a  methodology  is  needed  to  enable  the  transition 
from  the  semantic  net  representation  (functional  schema)  to  the 
Petri  net  representation.  This  transition  should  preserve  all  the 
sequencing  information  captured  by  the  functional  specification  of 
the  design. 

This  section  describes  such  a  methodology.  The  transition 
from  the  semantic  schema  to  the  Petri  net  representation  is 
accomplished  by  identifying  several  special  arrangements  among 
functions  in  the  functional  schema  and  instantiating  corresponding 
Petri  net  control  objects  into  the  Petri  net  under  construction. 
These  special  functional  arrangements  and  the  corresponding  Petri 
net  control  objects  are  described  below: 

1.  The  Aggregation  association,  as  previously  discussed,  does 
not  impose  any  ordering  constraints  on  the  execution  of  its 
subfunctions.  This  association,  therefore,  can  be  used  to 
explore    concurrency.       An    Aggregation    association    can 
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correspond   to    either    a    concurrency    or   a    sequential-type 
Petri  net  control  object.     This  is  illustrated  in  Figure  32a. 

2.  Unlike  the  Aggregation  association,  the  Functional 
Aggregation  imposes  an  ordering  on  its  subfunction 
execution.  Therefore,  it  only  corresponds  to  a  sequential 
type  Petri  net  control  object  (see  Figure  32b). 

3.  In  the  Functional  semantic  schema  a  Generalization 
association  captures  the  semantics  of  a  selection.  The 
corresponding  selection-type  Petri  net  control  object  is 
shown  in  Figure  32c. 

4.  An  Iteration  association  (R:S)  captures  the  semantics  of 
looping.  The  corresponding  Petri  net  control  object  is 
shown  in  Figure  32d.  Note  that  a  token  is  output  only  after 
executing  over  all  the  elements  in  the  Iteration  set  S. 

Figure  33  shows  the  stepwise  refinement  involved  in  deriving 
the  Petri  net  corresponding  to  the  functional  schema  of  Figure  29, 
using  the  rules  in  Figure  32.  The  labels  on  the  transitions  indicate 
the  function  performed.  Further,  those  labels  can  be  considered  as 
the  controls  part  of  the  controls/controled_by  link  for  those  blocks 
corresponding  to  active  agents.  The  corresponding  controled_by 
links  have  not  been  illustrated  in  the  structure  diagram  of  Figure  5 
in  order  to  reduce  clutter. 
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Referring  to  Figure  29,  note  that  the  Populate  PCB  function 
(root  node)  is  a  functional  aggregation  of  three  subfunctions.  The 
first  subfunction  is  in  turn  an  aggregation  of  two  other 
subfunctions,  namely  feed  components  and  feed  board.  Let's  assume 
that  the  manufacturing  engineer  decided  that  the  two  subfunctions 
participating  in  the  A  association  are  to  be  executed  concurrently. 
In  this  case,  the  A  association  branch  corresponds  to  the  first  PN 
variation  of  Figure  32a.  Similarly  the  F  association  corresponds  to 
the  PN  of  Figure  32b.  The  corresponding  PN  of  the  combination  F-A 
branches  is  shown  as  Step  1  in  Figure  33.  Moving  to  a  level  lower  in 
the  functional  schema  we  see  that  the  Populate  Board  function 
defines  an  iteration  association  on  the  function  Process  Component. 
Using  the  corresponding  PN  as  shown  in  Figure  32d,  we  can  refine 
the  Populate  Board  function,  as  shown  in  Step  2  of  Figure  33. 
Continuing,  the  function  Process  Component  can  be  refined  according 
to  Figure  32b,  resulting  in  Figure  33,  Step  3.  As  seen  from  Figure 
29,  Prepare  makes  use  of  the  G  association  in  order  to  select  the 
appropriate  subfunction  to  be  executed  depending  on  the  type  of 
component  to  be  processed.  In  expanding  the  Prepare  function,  we 
make  use  of  Figure  32c.  Step  4  in  Figure  33  shows  the  PN 
corresponding  to  the  Prepare  function  after  fully  expanding  its 
subfunctions.  Expanding  the  Test  and  Insert  functions  (Figure  29)  is 
done  by  using  Figure  32b  and  is  shown  as  Steps  4  and  5  (Figure  33). 

It  should  be   noted   here  that  the  resulting   Petri   net  is  by  no 
means  a  complete  description  of  the  workcell  control  structure.     It 
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is  rather  a  skeleton  which  constitutes  a  first  iteration  through  the 
WC  control  development.  The  manufacturing  engineer  is  responsible 
for  further  developing  this  control  skeleton  into  a  comprehensive 
control  structure.  A  comprehensive  control  structure  would  include 
error  detection  and  recovery,  synchronization  objects,  definition  of 
processing  delays,  etc. 

The  methodological  transition  from  the  Functional  semantic 
net  representation  to  the  Petri  net  representation  provides  the 
manufacturing  engineer  with  a  good  starting  point  in  developing  the 
WC  control  structure.  Further,  this  methodology  guarantees  a 
starting  point  consistent  with  the  high  level  design  specifications 
captured  by  the  functional  semantic  schema. 

The  scope  of  this  dissertation  does  not  address  all  the 
substeps  in  control  implementation.  However,  we  parenthetically 
remark  that  by  1)  labeling  terminating  conditions,  test  conditions 
and  actions  in  the  Petri  net  schema,  2)  mapping  control  objects  to 
physical  controllers  available  in  the  workcell,  and  3)  establishing  a 
message-based  communication  among  control  processes,  the  Petri 
net  schema  can  be  converted,  for  example,  to  a  set  of  VAL-level 
programs.  These  VAL  programs  can  either  serve  as  skeletons  for 
device  drivers  in  the  workcell  or  as  drivers  in  a  computer  simulation 
of  the  workcell. 

Moreover,  the  important  issue  is  that  the  Petri  net  obtained  by 
proper  instantiation  and  combination  of  objects  from  the  knowledge 
base  provides  an  adequate  level  of  visibility  and  documentation  of 
the  control  even  for  complex  designs. 
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CHAPTER  9 
CONCLUSIONS 


We  have  presented  a  novel  object-oriented  data  modeling 
paradigm,  the  S-F-C  paradigm,  aimed  at  supporting  manufacturing 
workcell  simulation  and  design  from  the  conceptual  to  the 
implementation  level.  This  paradigm  identifies  and  individually 
models  structural  knowledge,  knowledge  about  the  physical  objects; 
functional  knowledge,  knowledge  about  the  behavior  of  objects;  and 
control  knowledge,  which  ties  the  function  and  structure  together  in 
such  a  way  as  to  accomplish  a  useful  task. 

Since  associations  such  as  Generalization  and  Aggregation  as 
defined  in  other  popular  database  models,  can  capture  only  the  static 
relationships  among  objects,  new  associations  were  introduced  in 
order  to  express  the  dynamic  information  inherent  in  the  functional 
description.  Semantic  associations  that  are  specific  to  the 
manufacturing  domain  are  also  included  in  the  model.  These 
associations  serve  as  the  connecting  links  among  the  functional, 
structural   and  control   knowledge. 

Our  model  enhances  the  OSAM*  semantic  diagrams  in  order  to 
represent  dynamic  behavior.  Other  constructs,  such  as  buffering,  are 
then  introduced  to  break  strictly  sequential  operations  and  introduce 
concurrency. 
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A  methodology  is  presented  that  enables  the  transition  from 
the  functional  semantic  net  to  the  Petri  net  representation.  Finally, 
a  design  methodology  is  presented,  which  shows  how  all  these  tools 
and  ideas  can  be  used  constructively  in  order  to  make  the  Workcell 
design  process  a  more  efficient,  scientific  and  methodological 
process. 

While  initial  experiences  with  laboratory  design  examples  look 
promising,  further  work  is  needed  to  extend  and  more  clearly  refine 
the  role  of  the  control  knowledge  in  the  design  process.  One  of  the 
problems  that  has  been  encountered  in  applying  the  design  procedure 
discussed  in  this  dissertation  is  that  control  knowledge  seems  to  be 
much  more  relevant  at  the  instance  level  than  at  the  class  level, 
where  a  simple  taxonomy  of  constructs  suffices. 

The  salient  feature  of  the  proposed  design  methodology  is  the 
fact  that  it  relies  extensively  on  advanced  database  concepts  to 
organize  and  manipulate  domain-specific  knowledge  and  data.  While 
many  issues  still  remain  to  be  explored,  our  preliminary  work 
suggests  that  semantic  and  object-oriented  data  models  can  play  a 
key  role  in  filling  the  gap  between  the  limited  capabilities  of  the 
empirical  methods  currently  in  use  for  manufacturing  workcell 
design  and  the  challenges  posed  by  worldwide  economic  competition 
and  advanced  manufacturing  concepts. 

The  recent  availability  on  the  software  market  of  packages 
with  built-in  features  such  as  an  equipment  library,  layout 
facilities  and  kinematic  and  dynamic  simulation  capabilities,  can 
greatly  streamline  the  development  of  a  comprehensive  environment 
fully  supporting  the  outlined  design  methodology.     We  plan  to  extend 
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the   support  provided   by   one   such   commercially  available   package 
adding   the    higher-level,    conceptual   steps   in   the   design    process, 
making   use   of  the   semantic   modeling   paradigm   discussed    in   this 
dissertation. 
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